Remote Field Revision
public
neoliminal - Wed, 2008-03-05 17:14
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.



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.