On Sat, May 16, 2009 at 5:48 AM, Andreas Grosam <agro...@onlinehome.de> wrote: > Given the complexity of Core Data (and the occasionally interspersed > warnings, that this stuff is no "entry level") it sounds silly that it would > not support database servers, that is, supporting multi-user, locking and > transactions.
Well then go ahead and call it silly. > Even more, it would in no way an exaggerated asset if it would seamlessly > support to create application servers, leveraging DO, and creating web > applications with minimal code changes starting from a single- or a client > server model. There is/was a technology for this called Enterprise Objects Framework, from which Core Data is descended. > If this would be really true, any serious database application could not use > Core Data. So, for what is it anyway? Storing the users preferences? > Creating your own local CD-collection application? It's a persistence framework for desktop applications. Why must these things be relegated to boring server-side apps? Now any application gets a persistence framework for pretty much free. If you want client/server, you're more than welcome to implement it or use a framework that does it for you, but Core Data is not that framework. Besides, you should probably avoid serializing objects over a network connection, it tends to be a very tricky endeavor, especially in Objective-C. > I really can‘t believe this. It would be a great faux-pas! Do I really miss > something? Is this limitation anywhere documented? You say "limitation," the rest of the world says "design principle." --Kyle Sluder _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
