Dru,
I am not sure if I understand you, but here it goes! > Actually, there is no reason CoreData can't be used in this manner, but there > are things that will have to be dealt with outside of CoreData. How do you > deal with two people making changes to the same record concurrently as an > example ( this is not an issue exclusive to CoreData, but multi-user design ). The approach that Brad and I are talking about involves CoreData *only* in the client to manage a local cache of data objects that would be persisted after (and if) edited. This makes it easy to use bindings on the interface, solving *one* of the problems we discussed earlier on this thread. Instead of persisting data on a "local" NSPersistentStore (XML, SQLite, whatever), you replace it with an NSIncrementalStore subclass that communicates with a web/application server on the internet or LAN. This app server becomes the persistent store and, ideally, would deal with the concurrency and locking. This app server, these days, is commonly a RESTful web service (written in Rails, PHP, WebObjects/WOnder or whatever), hence the popularity of AFIncrementalStore/AFRESTClient. > I find this frustrating, because EO was truly revolutionary and even today > competes well against similar projects, and it hasn't been actively updated > for at LEAST > 5 years. Well, the guys on the webobjects-dev list would strongly disagree! :) Best regards, Flavio _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
