Enterprise App Development, easy as Core Data?

Hi Ryan,

I've read your three threads and have been idly thinking about them for a couple of days. I know nothing about this really so forgive the musings and thoughts. I read this one first so I chose it to reply to.

When I first read it I initially thought "what's stopping you use CoreData?". It certainly easy enough to alter the location of the data file (and the datatype it's saved as), so presumably it would be possible to locate the data on an external volume somewhere and incorporate some form of mounting and error checking routines before the file is committed.
Then I realised the obvious problem with this relative to what you're actually trying to achieve; namely multiple access by multiple people on various machines, presumably often at the same times. How do you manage simultaneous concurrent access to the same file? I started to then think that this still might be possible with CoreData but by taking a slightly different view. Perhaps implement the application as a desktop app that uses it's own data file on a local volume (probably the normal location ~/Library/Application Support/xxx) to keep changes separate from other users working at the same time and then write other code that manages synchronising with the main file(s) on the server volume. Perhaps using a versioning system like svn for this part. The app could then checkout the master datastore from the server, alter it, save it locally and then when the session's over call the versioning system to update and compare the changes.
This might work if the situation fits but there's obviously large problems with users working on differing data in realtime and other such clumsiness.

On the other hand, I think Cocoa can be used in the manner you want using NSConnection and Distributed Objects. Have a look at this tutorial at CocoaDevCentral about writing a client/server app. It also links to this article at Stepwise which also may be of some use. A must read would also be Apple's docs on the topic of Distributed Objects which are here.

A well known app that offers multiple simultaneous user access to the same file is SubEthaEdit which might also be worth a look.

I'm sorry I can't be any more help and hopefully someone more knowledgeable than I will chime in with better observations/solutions, but no matter which way you choose to approach the problem I think there's going to be some serious coding involved.

Ryan - I've been looking for a way to integrate signature capture into my point of sale solution. Wonder if you'd share your experience off list.

Thanks.

I too really like CoreData, and have been playing around with it for a few weeks now.

After reading as much as I can about it I am confused why Apple continues to use XML in apps like iCal, addressbook and all preferences.

Apple admit this is the slowest method of storing CoreData file and they offer two faster alternatives; Binary and SQLite.

Why choose the slowest file format. I know XML is easy to read by developers but using SQLite can be as easy to. I would rather have the performance gain over XML anyday if I can use CoreData app to retrieve the information anyway.