Re: CoreData file format stability
Re: CoreData file format stability
- Subject: Re: CoreData file format stability
- From: Charles Srstka <email@hidden>
- Date: Tue, 3 Jun 2008 18:58:01 -0500
Thank you for your feedback.
On Jun 3, 2008, at 5:34 PM, Ben Trumbull wrote:
1) The file format for saved files. I'd rather not make some
proprietary/closed Microsoft-ish thing - I'd like it to be possible
for other programs to read/write my file format, including
hypothetical programs that might get written for other platforms so
that my file format could possibly be readable and writable by our
Linux friends (and Windows carbon units as well).
As Kyle notes, you could use a specific interchange format instead.
Many applications do something like this since the feature
requirements for cross platform sharing are usually not 100%
congruous with those for daily use. As an example, often people use
an XML format for interchange, but that's much too slow for day to
day work on large data sets.
The OmniFocus team wrote a blog post on what they did in this area
using Core Data.
Without going into more details than I'd like to reveal, an
interchange format is not a viable solution for the type of
application I am considering developing. The app needs to be able to
read and write the same files that will be transferred around, and it
needs to be able to edit files nonatomically.
This is not your largest concern. Your most significant issue is
whether or not you could even deploy such an application to other
platforms. Core Data is not an Objective-C wrapper around SQLite.
It is a Cocoa application development framework focused on the M in
MVC. The fact that it also does object persistence is perhaps it's
least interesting feature.
Assuming you wrote a Core Data application on OSX, you'd need to
reimplement nearly every Core Data feature you used on Linux or
Windows. This includes integration with your controller layer
(Cocoa Bindings), undo support, KVC & KVO equivalents, an entire
schema metadata class hierarchy, sophisticated relationship
modeling, and many other features.
Not really. I'm not concerned about deploying the app on other
platforms, and I'm not concerned about the feature set being exactly
the same either. All I want here is to make the app save files that
can be manipulated on other platforms. The application to do so may
not have the same name, it may not share any code with my app, it may
not have the same feature set, and it may not even be written by me.
All I want is for it to be possible to make an app at some point that
would be able to read and write the file with *some* software on other
platforms, much like MS Word, WordPerfect, and TextEdit can all read
and write RTF files without necessarily sharing any code or feature
sets. Basically, I don't want my file format to get locked into one
platform.
The app's not what needs to be portable - the file format is.
None of the Cocoa frameworks are focused toward helping people write
Linux or Windows software. The problems you'll have with Core Data
are the same ones you'll have with Cocoa Bindings, AppKit, and even
large portions of Foundation. Uhm, right, and Objective-C itself.
Yes, it's cross platform, but most software on Linux & Windows is
written in C/C++ or other languages and the platform specific
developer tools are geared toward that reality.
And none of the Linux or Windows frameworks are designed to create
best of breed cross platform software either.
It's not clear why you're even interested in Linux as a deployment
platform. Not bashing Linux, I was programming on SunOS boxes
twenty years ago and think Linux is just swell, but it's market
share for desktop applications is a fraction of 1%. And most people
with Linux have machines that can dual boot into Windows or OSX. If
you're writing a configuration tool for enterprise software, for
example, different features have priorities that would be considered
unusual for a consumer desktop application (and vice versa)
I would encourage you to consider developing your software with the
platform tools and frameworks best suited to that platform. When in
Rome ...
Most customers don't appreciate applications that fail to appear and
behave as native applications, and Windows and Linux have their own
set of frameworks for application development. Typically, it's
easier to leverage the platform frameworks than to fight them by
forcing designs from other platforms into their API. This places a
burden on you to design your custom logic more elegantly to plug in
to many different APIs, but it is possible, and generally the best
way to write high quality applications on multiple platforms.
Of course I understand this, which is why I want to develop this app
using Cocoa and whatever advanced features I can get away with using
without crippling the ability to port the file format (not necessarily
the app) to other platforms. Otherwise, I'd just be using wxWindows or
something and wouldn't be posting to this list. A Windows app to read
my file format would probably be written using .NET or whatever would
be able to give the app the best experience available over there, but
if the experience of the app on my favorite platform were better than
what you could get on Windows, it wouldn't break my heart, as long as
it could *work* on Windows.
You haven't really articulated your feature requirements, or how
important cross platform support really is to your application.
My requirements are simple:
1. The app must be able to edit a file in place, nonatomically.
2. The file must be able to grow to large sizes
3. The app needs to be possible to search the file quickly
4. The app must be for OS X and its user experience must be as nice as
I can make it, using whatever technologies will help me attain that
goal (i.e. it'll be a Cocoa app)
5. I'd *like* the app to be able to work on Tiger, although if it
required Leopard, that could probably still work
6. The file format needs to be open, either using open standards like
XML or open-source technologies like SQLite
7. I need to be able to document the format so that someday, someone
(either me or someone else) can write an editor for this file format
on a platform other than OS X.
Based on the information gathered so far in this thread, I am thinking
that CoreData would unfortunately not be the tool most appropriate for
this particular app, which is fine - I'm just exploring my options at
this point, to see what tools would be good to use for this
application and what tools wouldn't, and I'm exploring the new Cocoa
features like bindings and CoreData to try to break out of my "That's
how I've always done it" box. Bindings will work well for this app,
but it's looking like CoreData is probably the wrong tool for this
particular job.
Thanks for your input,
Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden