Re: CoreData file format stability
Re: CoreData file format stability
- Subject: Re: CoreData file format stability
- From: Ilan Volow <email@hidden>
- Date: Tue, 3 Jun 2008 21:18:24 -0400
- Domainkey-status: no signature
I'd suggest you check out QuickLite http://www.webbotech.com/ for the
time being.
But for the long term, the mac development community outside of Apple
really needs to come up with their own ORM/persistance framework that
can target a number of difference storage technologies (PostgreSQL,
MySQL, SQLite), and provides adequate documentation to ensure the
recoverability of data stored in that format. Stability issues aside,
CoreData is already pretty limited for business applications because
support for multi-user databases is non-existent, and I don't expect
this to change in 10.6.
So, I wonder how many people on the list would be in participating in
a "MoreData" project?
-- Ilan
On Jun 3, 2008, at 7:58 PM, Charles Srstka wrote:
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
_______________________________________________
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