Re: Cocoa stripping resource forks: does Jaguar fix?
Re: Cocoa stripping resource forks: does Jaguar fix?
- Subject: Re: Cocoa stripping resource forks: does Jaguar fix?
- From: Pierre-Olivier Latour <email@hidden>
- Date: Thu, 04 Jul 2002 20:20:12 +0200
>
There's a price though: this code does not, and never could, of course,
>
support all those Mac proprietary tricks. In other words, it is relatively
>
unimportant whether your or mine applications would preserve resource
>
forks or not, since ALWAYS there will be some ported code which would not,
>
and therefore using resource forks is and always will be inherently
>
unsafe (well, unless you stick with a very small number of carefully
>
tested applications).
I guess you are overreacting: making voluntary all apps behave bad because
some of them do is not a solution.
The point is not about resources forks being used in the future or not: we
all agree on the fact that Apple does not want to keep them. Therefore,
application built _from now on_ should not use them, but use data-based
resource files, bundles and so on...
The point is not either that all Cocoa developers change their code to
support resource forks.
The problem is simply, according to the person who started the thread, that
current Cocoa implementation do not respect resource forks. We're not
talking about creating ones, just avoid to destroy them in case an
application has stored essential data into them. It wouldn't be much work
for Apple to fix in the underlying Cocoa API and you won't even have to
touch your code.
Do not forget there are far more carbon applications than Cocoa ones right
now. There are also billions of lines of code of MacOS Classic code. Former
Next-users or Unix-users are also a niche market compared to "real" Mac
users on OS X.
OS 9 may be dead for Apple, but not for users: the ratio between OS X users
VS Classic users is still way way below 1 (especially considering hardware
requirements for OS X). Their OS not being "official" any more does not mean
we should happily destroy all their data or not be able to read it.
In this case, the minority (us) has to adapt to the majority. After all,
that exactly what Apple is doing by dropping Type and Creator codes to be
100% compatible with other OSes, no?
I give you another example: Cocoa applications do not create files with type
and creator codes. That's Apple decision, OK. It's still somehow compatible
with "classic" MacOS as long as the file as standard extensions (.jpg, .txt
and so on). However, there are billions of files out there on Macs that do
not have any extension. Creating a Cocoa application that is not able to
open any of these files because of this is a non-sense (they won't appear in
open dialogs). Therefore, Apple provides a way for files without extensions
to be opened transparently into Cocoa apps (in Project Builder's document
list).
Talking about portability: I don't think it's really a factor here, since
Cocoa = MacOS X only. End of story, unfortunately.
However, I'm wondering, do all file systems support extensions with more
than 3 characters or folder with extensions in their name?
_____________________________________________________________
Pierre-Olivier Latour email@hidden
Manager and Lead Programmer
French Touch software
http://www.french-touch.net
Cool source code:
http://www.french-touch.net/CodeWareHouse
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.