Re: Resource Fork - is this a good use/the right thing to do?
Re: Resource Fork - is this a good use/the right thing to do?
- Subject: Re: Resource Fork - is this a good use/the right thing to do?
- From: Daniel DeCovnick <email@hidden>
- Date: Wed, 23 Apr 2008 23:55:09 -0400
The problem with that is, as I wrote in my first message, the real
data files aren't mine, and won't be opened by my app exclusively. The
data that I need to save ought to be invisible to the file's owner.
Imagine, for example, that when working on a file in HexEdit, it
allowed you to highlight in different colors and annotate locations in
a file. Where would HexEdit save those annotations and locations and
colors of highlighted areas?
-Dan
On Apr 23, 2008, at 11:33 PM, Jason Stephenson wrote:
Chris Suter wrote:
Furthermore, it doesn't follow the file which was the original
design goal.
Going back to the original question, I personally think that the
best thing to do is to just create another file and educate the
user. Extended attributes and resource forks are all very nice but
most users don't understand what they are and they just don't
interoperate nicely with other systems.
My first thought on reading this thread is that it would be easiest
just to store the data in a zip-type archive file. You could then
have all the metadata/resource files included in an archive
subdirectory, and everything would transfer nicely across operating
systems. OpenOffice.org does this. All of the components of a
document are stored in a zipped archive that just happens to have
the .odt or .od-whatever extension.
Using an archive file format solves the issue of user education,
since it appears to be a single file to the user, gives the
programmer the option of including whatever arbitrary resources are
needed for this particular file, and also solves the issue of
operating system portability, since just about any OS in current use
can handle copying a binary file around.
Just my 2d....
Cheers,
Jason
_______________________________________________
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