On Jul 17, 2012, at 7:05 AM, Flavio Donadio <fla...@donadio.com.br> wrote:
> I already took a look at NSIncrementalStore and it seems to solve one of my > problems. I am fairly good with PHP, but I could always create a web service > with Rails or something else… On the client side, it doesn’t matter what you use on the server side to create a web service. And vice-versa. > One of my gripes with using HTTP as the client-server base protocol is the > request-response loop. This breaks a lot of desirable features. In my > particular case, I want my users to receive "real-time" updates when other > users edit records on the database (not really "real-time", but at least > after a COMMIT on the database). Very few systems will actually do this for you, as it’s almost always *not* a desirable feature. For example, even if you use NSIncrementalStore to implement Core Data access to a web service, you won’t get this kind of functionality. In general, users A and B may both be looking at their own internally-consistent data sets. If user A changes something that’s also part of what user B is looking at, you almost always want to keep user B’s view of the data the same until they either explicitly choose to refresh their view, or until they actually attempt to save their own changes. At that point you can allow user B to resolve the conflict between their own changes and user A’s changes to the same objects. This is part of why there’s no “easy multiuser” in data management frameworks: The choices that need to be made often boil down to user experience, and can vary dramatically from one application to the next. -- Chris _______________________________________________ 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
