Josh,
On Apr 28, 2010, at 10:57 AM, Joshua Tidsbury wrote: > The application is essentially a server side app that will manage various > background file moving/archiving processes and store metadata about the files > in a database. The heavy lifting in terms of file analysis and moving the > materials around and storing the metadata in the database will entirely be > done by a Cocoa application running on a server. I don't really understand the need for a Cocoa app on the server. The web app will only handle file operations and metadata storage on the database? If this is the case, maybe you can drop Cocoa entirely. > I want the end users to be able to browse/search the metadata from a web > based application for the sake of cross-platform compatibility, and > ultimately their actions within the web app will trigger jobs within the > server app. I was planning on some sort of SOAP interface in the Cocoa app to > accept commands from the web application to trigger the jobs. So, you need to move files around and store metadata on the database. Why don't you do it in PHP or Rails? PHP comes with Mac OS X and can be easily updated through packages. Rails can be easily installed. I am not an expert in Rails, but I believe that, like PHP, it can access your filesystem. In PHP, besides all of the filesystem handling functions, you can always use exec() to access command line tools like ditto if, for example, you need to handle resource forks. This way, you can have a pure web application and won't have to deal with the current lack of RDBMS Frameworks for Cocoa. Unless you need something that only Cocoa can offer... Cheers,_______________________________________________ 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
