Remote Field Revision
This discussion will revolve around issues of Remote Field Revisions. This regards getting field population from single, multiple, and unknown sources. Sending data to other sites and how they can use, modify, and potentially change that data from source. Also regarding race state and origination of data sources and trusted sources for field revision.
Groups:
Login to post comments

field flowing on servers recursively A -> B -> A -> B
If a field is replicated on two machines and each is pointed to the other you have potential for recursion.
Example:
Possible solution sets:
Local revisions control of fields. A -> B(b) !-> C
If a server sends a field, the secondary server should have the ability to revise the field and not forward on the revised field (keeping it as a local change only.) It should still forward on the original field.
Example:
Possible Solution:
Multiple Field sources that don't agree. A -> C(a), B -> C(b)
A server can aggregate a Field from multiple sources. A system needs to be created to prioritize source input should these Fields disagree.
Example:
Possible Solutions:
Receiving Servers find erroneous Field Data A -> B(x) -> A(x)
If a Field is send from a server and it's data is either NULL, inaccurate, munged or otherwise unusable, there should be a mechanism for the receiving site to notify the first server that the data is invalid.
Example:
Possible Solutions:
Questions:
We discussed this a bit at
We discussed this a bit at DrupalCon and I asked John to post these issues to be sure we have them documented. These are the kinds of things we'll need to keep in mind as we work out the details.
I see little discussion
I see insufficient discussion about anything but local, database-stored fields in all of the discussion. We will be severely limiting what Drupal can do if we don't consider and architect for remote data sources for fields.
We should be able to provide something like CCK-based content types which have some fields which are local to the database, and others which may be drawn from other APIs (e.g. web services). The demand for such things is already there (see Robert Douglass's posts regarding proxy-node sites, Larry Garfield's posts 3rd party data, etc.).
Web Services fields.
Are you considering relying on external api's from other sites on each load of a field? Otherwise we need local copies, at least in cache, in order not to run into speed issues. We also want to be respectful of other's bandwidth/processors and not request fields from other sites on an ad-hoc basis.
This all points to local versions of these fields in the drupal database, while they will be getting the data originally from some other source.
If this isn't what you're talking about then I'm missing something.
--
John Kipling Lewis
Need both / all of the above
Thanks for your reply.
I think we need both the ability to pull cached copies from remote sites (with several methods of expiring and refreshing cache, e.g. cron or age), and the ability to hit other sites on load of the field.
I would agree that in most cases, the former caching solution would be preferred, exactly for the reasons you state (speed, respect).
However, there are some situations where immediate access from another site is feasible and desirable. When the other site is both designed for such use, and when currency of the data displayed is a priority over speed of displaying, then non-caching solutions might be the choice.
I'm working on a situation more similar to the latter than the former right now. I have a very light-weight REST API to retrieve a representation of a resource the other system has. I could do a direct connect to the other system's database, but that solution does not scale or manage very well from a complexity and security point of view.
Still, I do agree local versions of remote fields in the Drupal database is something we really need.