![](https://secure.gravatar.com/avatar/2e8a29939ae47bcb3f13355216707cfe.jpg?s=120&d=mm&r=g)
On Jul 11, 2012, at 9:53 PM, Barry Warsaw wrote:
On Jul 11, 2012, at 09:27 AM, Richard Wackerbarth wrote:
First, we should define all of the data storage in terms of the REST access points to the data. (And not, as presently done, the other way around) Next, we should access all of the REST interface URLs indirectly so that functionality can be moved around simply by changing a single reference definition. This is the kind of scheme that django uses with its {% url %} tag. (like DNS vs IP addresses) Finally, we should "black box encapsulate" the access to the data, requiring that EVERY module utilize this common interface, and only this interface, to the data.
If there were a separate user database that exposed all sorts of data via REST, including stuff the core doesn't care about, then all the things I described before about re-implementing various Zope interfaces in the core holds true. They would just do REST calls instead of database queries.
Agreed.
Both implementations in fact can live side-by-side, and choosing one or the other is something you do when you install and configure the system.
I'm not sure that I agree with attempting to maintain two implementations "side-by-side"
"separate, but equal" comes to mind. And we all know how that worked.
My preference remains to use the REST interface to define the object contract. By that, I mean that every action performed on the object is isomorphic to a REST interaction.
To do otherwise creates an inequality between those accessing the object.
-Barry