[quote]Apple seems to have rewrote it because of the developer input.<hr></blockquote>
Sorry, I thought "it" referred to the Aqua human interface guidelines, not the now-infamous TNxxx.
That said, the main developer objections to the technote centered on the apparent deprecation of the C++ language and the preference for POSIX-style paths rather than FSSpecs. It was only tangentially a metadata issue.
The objectionable metadata stuff is in the Aqua human interface guidelines which have been out for many months and have not been pulled or changed, despite strong developer objections.
[quote]I don't see anything wrong with saying, "well other's disagree with you."
It may not be my own opinion, but it is still hear say information that carries weight. That's like asking, why should I run if I only hear employees scream fire. Obviously, I won't go look for the fire to find out myself if I should run.
If you want my own opinion, you didn't have to ask so harshly, Starfleetx.
My opinion is to put it very bluntly,
"Let my betters in this area decide for me". Think for one's self, but don't think too hard applies.<hr></blockquote>Oh, that's just fine. Sorry if I came across as a little bitter or harsh earlier; it's just that this is a very important issue to me. I simply wanted to understand a bit more of your opinion since I couldn't quite get where you stood on the matter.
Play it cool. :cool:
And, John, do you have a general date in mind that you plan to officially send all this to Apple?
[quote]John, do you have a general date in mind that you plan to officially send all this to Apple?<hr></blockquote>
I was hoping for 10,000 signatures, but I'm not sure we're going to make that any time soon. I'm thinking of sending it off as early as Monday. But regardless of when I send it, the petition wil remain up, and the submission will point to it as an "ever-growing" list of supporters.
Second, if she did ever try to FTP a file named "My Letter" somewhere, the Mac would not only warn her (but in much nicer non-technical language, of course), but offer to fix the situation for her by appending the appropriate extension based on the file type. All she would have to do is click a button.
</strong><hr></blockquote>
Which might work for the built-in FTP app, but not necessarily for third party apps.
Even worse, what if there's a NFS volume mounted into the file system (server-sided home directories for example)? This happens transparently to the user, and (well, in theory) to applications and the upper layers of the OS - i.e. the OS provides layers of abstraction on top of filesystems, so individual applications don't (and shouldn't) (have to) know about the implementation details of the specific filesystem they are trying to save a file to.
What I mean is, under OS X there are some situations where the "gate keeper takes care of metadata" approach doesn't work, because there is no obvious gatekeeper as in the case of emails with attachments.
Besides, on Windows for example, hidden file extensions work pretty well in daily use (at least for most windows users I know of), and are nowhere near being a pain in the ass.
[quote]"Second, if she did ever try to FTP a file named "My Letter" somewhere, the Mac would not only warn her (but in much nicer non-technical language, of course), but offer to fix the situation for her by appending the appropriate extension based on the file type. All she would have to do is click a button. "
Which might work for the built-in FTP app, but not necessarily for third party apps.<hr></blockquote>
First, once again, this conversion would not be necessary at *unless* the user explicitly chose to configure their Mac in this way (e.g. turning off the preference to append file name extensions to every file saved by a Mac OS X application)
Second, why should "third party [Mac] apps" behave so differently? Are Mac software developers suddenly going to go crazy? Using your reasoning, you might as well condemn everything in Mac OS X, from application bundles to the Aqua look and feel. "That might work for the built-in apps, but not necessarily for third party apps." Silly reasoning, IMO.
[quote]Even worse, what if there's a NFS volume mounted into the file system (server-sided home directories for example)? This happens transparently to the user, and (well, in theory) to applications and the upper layers of the OS - i.e. the OS provides layers of abstraction on top of filesystems, so individual applications don't (and shouldn't) (have to) know about the implementation details of the specific filesystem they are trying to save a file to. <hr></blockquote>
Individual applications wouldn't have to know all the details, They'd deal with this stuff through a nicely abstracted API provided by the proposed metadata services framework.
[quote]What I mean is, under OS X there are some situations where the "gate keeper takes care of metadata" approach doesn't work, because there is no obvious gatekeeper as in the case of emails with attachments.<hr></blockquote>
The proposal does not specify exclusive use of (or necessarily any use of) the so-called "gatekeeper" approach. (And, incidentally, there is always some piece of software in the "gatekeeper" position.) As for email attachments, I invite you to look at the mail preferences for Entourage X for an example of how mail attachments can be handed in OS X even without the convenience of a the proposed metadata services framework.
[quote]Besides, on Windows for example, hidden file extensions work pretty well in daily use (at least for most windows users I know of), and are nowhere near being a pain in the ass.<hr></blockquote>
Windows works pretty well for Windows users (at least for most windows users I know of), and is nowhere near being a pain in the ass. Perhaps we should all use Windows...?
[quote]As far as being cross-platform and standard-compliant, I actually think apple should go with the file extensions. Mac metadata gets yanked out when moved to any platform other than Mac. It's a pain in the ass. Having .txt and .psd and .doc isn't that big of a deal.<hr></blockquote>
The point of the metadata issue is that cross-platform compatibility should not make using OSX inherently more difficult or complicated. If I choose or need to move a file to another platform, the apps I use or I can append the filename to add a file extension. Note that this file "movement" is not something that all users will do, and dumbing down the OS for this single aspect of cross-platform compliance seems silly.
The beauty of OS9 is creating a file in an app, and later double-clicking on that file and knowing that the app that I used to create that file will open that file. No maybes, or should haves. Files coming from a PC can be assigned an app thorugh PC Exchange, and if there are any problems it is because PC Exchange has not had an UI attention since it was introduced.
If my OS is going to behave like Windows why not use Windows, after all there are more apps and the hardware is cheaper.
John isn't arguing for Apple to keep its old forked filesystem except as a short-term provision. In fact, he advocates getting rid of it. You can store file metadata in any number of different ways, including in packages (directories) and separate databases. In fact, this is already a solved problem: Mac OS X preserves HFS+ metadata on UFS volumes already through a little magic.
The Metadata petition's complaint is that the only file metadata Apple is acknowledging for OS X seems to be filename suffixes, and it is looking to establish an API and a set of services to provide high-level, implementation-independent access to a rich set of file metadata. How it happens to be stored is irrelevant.
[quote]There is now an <a href="http://www.PetitionOnline.com/osxnomd/petition.html"; target="_blank">anti-metadata petition</a>. The relative strengths of the two sides of this issue will be interesting to know.<hr></blockquote>
Abandon hope all ye who enter here... <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
<strong>The anti-metadata petition misses the point.
* snip *
The Metadata petition's complaint is that the only file metadata Apple is acknowledging for OS X seems to be filename suffixes, and it is looking to establish an API and a set of services to provide high-level, implementation-independent access to a rich set of file metadata. How it happens to be stored is irrelevant.
</strong><hr></blockquote>
Very true, and I certainly agree with most of John's ideas. It probably would have diluted the impact of his proposal, but I wish he had mentioned the file path issue as well... that one just pisses me off to no end.
The usage of metadata was to give users an easier time with handling files.
As of right now, OSX tries it's best(the windows way with some mac)
What John proposes feels like more power version of PC exchange.
Now here's the thing. Is there a knowledge enough administrator, especially in common house holds, to configure this properly, not misuse it, and debug it if necessary?
IF you do have a skill enough administrator to use the proposed metadata, what's the point? They would equally be able to handle the 'Windows' way as easily, thus very wouldn't care less.
Superior user experience sounds all kewl and neat, but to make it work right to make it superior. It's almost paradoxal.
[quote]It probably would have diluted the impact of his proposal, but I wish he had mentioned the file path issue as well... that one just pisses me off to no end.<hr></blockquote>
Me too, and there is some mention of it in there, mostly just because it was in the first draft and I didn't remove it. But I the topic deserves a whole new proposal of its own (don't even think of looking at me, heh ;-)
Or maybe not. This little bit from the proposal basically says it all, IMO:
[quote]"3. THE ROBUSTNESS OF FILE IDENTIFICATION AND ASSOCIATION IS MORE IMPORTANT THAN PERFORMANCE MINUTIA WHEN IT SERVES TO PROVIDE A SUPERIOR USER INTERFACE.
While simple "paths" may have better performance than more abstracted file identification and tracking mechanisms, the user interface provided by the abstract mechanisms is worth the trade-off. The fact that more primitive operating systems do not "natively" support these abstractions is not an adequate reason to deprecate or abandon them.
Moreover, any performance penalties and historic limitations inherent in such file access abstractions should be eliminated, not by eliminating or decreasing the abstraction, but by creating new, more advanced implementations of these abstractions in Mac OS X."<hr></blockquote>
After that, it's all over but the shouting, IMO. But maybe some hard core developers would have specific API issues that they could expand on.
But from a user's perspective, people just want stuff not to break. Upgrade IE and the Dock suddenly has a question mark in it? Lame. I should be able to do what I do in Mac OS 9. Start downloading a file, then move the file while it's downloading? No problem! Start copying a large file and then 1) move the file, 2) rename the folder it's in, and 3) rename the volume the file is on? Hey, Mac OS 9 is right there with me. That, as Darth Vader said in that Arnie movie, is power
[quote]IF you do have a skill enough administrator to use the proposed metadata, what's the point? They would equally be able to handle the 'Windows' way as easily, thus very wouldn't care less.<hr></blockquote>
What "skill" is required? The OS has the "skill." The user just has options (or can simply accept the defaults, whatever they may be).
[quote]Superior user experience sounds all kewl and neat, but to make it work right to make it superior. It's almost paradoxal.<hr></blockquote>
The proposal underestimate some things and over estimate others.
It says, it must be robust, expandable with high speed journalism, that is standardized.
The 4 great words of tech community. And half of them never come out right. It will be bickered, hacked, be bug ridden, and as I like to say, "Mircosofted"
Even with the imperfect results I'm sure technogy will emerge, in debatable quality.
But there would be more trade off along the way, and with it more options and "Skills' needed to handle it.
Realisticly. On something as a 'niche' system, "default" will never be enough in our increasingly big melting pot.
To accommodate it this, there is user customization process, like pc exchange(I guess). And that requires SKILL.
7777 signatures so far. (I was lucky on this one )
I don't mind to add an extension since I came from Windows world. Usually I keep it as a easily, quickly readable reminder of the nature of a file. But I would like to be able to choose : sometimes, I like no extension on a file and when I change things It begins to create mess...
Comments
Sorry, I thought "it" referred to the Aqua human interface guidelines, not the now-infamous TNxxx.
That said, the main developer objections to the technote centered on the apparent deprecation of the C++ language and the preference for POSIX-style paths rather than FSSpecs. It was only tangentially a metadata issue.
The objectionable metadata stuff is in the Aqua human interface guidelines which have been out for many months and have not been pulled or changed, despite strong developer objections.
I hope my earlier reply makes more sense now.
It may not be my own opinion, but it is still hear say information that carries weight. That's like asking, why should I run if I only hear employees scream fire. Obviously, I won't go look for the fire to find out myself if I should run.
If you want my own opinion, you didn't have to ask so harshly, Starfleetx.
My opinion is to put it very bluntly,
"Let my betters in this area decide for me". Think for one's self, but don't think too hard applies.<hr></blockquote>Oh, that's just fine.
Play it cool. :cool:
And, John, do you have a general date in mind that you plan to officially send all this to Apple?
I was hoping for 10,000 signatures, but I'm not sure we're going to make that any time soon. I'm thinking of sending it off as early as Monday. But regardless of when I send it, the petition wil remain up, and the submission will point to it as an "ever-growing" list of supporters.
<strong>
Second, if she did ever try to FTP a file named "My Letter" somewhere, the Mac would not only warn her (but in much nicer non-technical language, of course), but offer to fix the situation for her by appending the appropriate extension based on the file type. All she would have to do is click a button.
</strong><hr></blockquote>
Which might work for the built-in FTP app, but not necessarily for third party apps.
Even worse, what if there's a NFS volume mounted into the file system (server-sided home directories for example)? This happens transparently to the user, and (well, in theory) to applications and the upper layers of the OS - i.e. the OS provides layers of abstraction on top of filesystems, so individual applications don't (and shouldn't) (have to) know about the implementation details of the specific filesystem they are trying to save a file to.
What I mean is, under OS X there are some situations where the "gate keeper takes care of metadata" approach doesn't work, because there is no obvious gatekeeper as in the case of emails with attachments.
Besides, on Windows for example, hidden file extensions work pretty well in daily use (at least for most windows users I know of), and are nowhere near being a pain in the ass.
Bye,
RazzFazz
Which might work for the built-in FTP app, but not necessarily for third party apps.<hr></blockquote>
First, once again, this conversion would not be necessary at *unless* the user explicitly chose to configure their Mac in this way (e.g. turning off the preference to append file name extensions to every file saved by a Mac OS X application)
Second, why should "third party [Mac] apps" behave so differently? Are Mac software developers suddenly going to go crazy? Using your reasoning, you might as well condemn everything in Mac OS X, from application bundles to the Aqua look and feel. "That might work for the built-in apps, but not necessarily for third party apps." Silly reasoning, IMO.
[quote]Even worse, what if there's a NFS volume mounted into the file system (server-sided home directories for example)? This happens transparently to the user, and (well, in theory) to applications and the upper layers of the OS - i.e. the OS provides layers of abstraction on top of filesystems, so individual applications don't (and shouldn't) (have to) know about the implementation details of the specific filesystem they are trying to save a file to. <hr></blockquote>
Individual applications wouldn't have to know all the details, They'd deal with this stuff through a nicely abstracted API provided by the proposed metadata services framework.
[quote]What I mean is, under OS X there are some situations where the "gate keeper takes care of metadata" approach doesn't work, because there is no obvious gatekeeper as in the case of emails with attachments.<hr></blockquote>
The proposal does not specify exclusive use of (or necessarily any use of) the so-called "gatekeeper" approach. (And, incidentally, there is always some piece of software in the "gatekeeper" position.) As for email attachments, I invite you to look at the mail preferences for Entourage X for an example of how mail attachments can be handed in OS X even without the convenience of a the proposed metadata services framework.
[quote]Besides, on Windows for example, hidden file extensions work pretty well in daily use (at least for most windows users I know of), and are nowhere near being a pain in the ass.<hr></blockquote>
Windows works pretty well for Windows users (at least for most windows users I know of), and is nowhere near being a pain in the ass. Perhaps we should all use Windows...?
The point of the metadata issue is that cross-platform compatibility should not make using OSX inherently more difficult or complicated. If I choose or need to move a file to another platform, the apps I use or I can append the filename to add a file extension. Note that this file "movement" is not something that all users will do, and dumbing down the OS for this single aspect of cross-platform compliance seems silly.
The beauty of OS9 is creating a file in an app, and later double-clicking on that file and knowing that the app that I used to create that file will open that file. No maybes, or should haves. Files coming from a PC can be assigned an app thorugh PC Exchange, and if there are any problems it is because PC Exchange has not had an UI attention since it was introduced.
If my OS is going to behave like Windows why not use Windows, after all there are more apps and the hardware is cheaper.
[ 12-09-2001: Message edited by: Fluffy ]</p>
John isn't arguing for Apple to keep its old forked filesystem except as a short-term provision. In fact, he advocates getting rid of it. You can store file metadata in any number of different ways, including in packages (directories) and separate databases. In fact, this is already a solved problem: Mac OS X preserves HFS+ metadata on UFS volumes already through a little magic.
The Metadata petition's complaint is that the only file metadata Apple is acknowledging for OS X seems to be filename suffixes, and it is looking to establish an API and a set of services to provide high-level, implementation-independent access to a rich set of file metadata. How it happens to be stored is irrelevant.
[ 12-09-2001: Message edited by: Amorph ]</p>
Abandon hope all ye who enter here... <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
<strong>The anti-metadata petition misses the point.
* snip *
The Metadata petition's complaint is that the only file metadata Apple is acknowledging for OS X seems to be filename suffixes, and it is looking to establish an API and a set of services to provide high-level, implementation-independent access to a rich set of file metadata. How it happens to be stored is irrelevant.
</strong><hr></blockquote>
Very true, and I certainly agree with most of John's ideas. It probably would have diluted the impact of his proposal, but I wish he had mentioned the file path issue as well... that one just pisses me off to no end.
The usage of metadata was to give users an easier time with handling files.
As of right now, OSX tries it's best(the windows way with some mac)
What John proposes feels like more power version of PC exchange.
Now here's the thing. Is there a knowledge enough administrator, especially in common house holds, to configure this properly, not misuse it, and debug it if necessary?
IF you do have a skill enough administrator to use the proposed metadata, what's the point? They would equally be able to handle the 'Windows' way as easily, thus very wouldn't care less.
Superior user experience sounds all kewl and neat, but to make it work right to make it superior. It's almost paradoxal.
~Kuku
Me too, and there is some mention of it in there, mostly just because it was in the first draft and I didn't remove it. But I the topic deserves a whole new proposal of its own (don't even think of looking at me, heh ;-)
Or maybe not. This little bit from the proposal basically says it all, IMO:
[quote]"3. THE ROBUSTNESS OF FILE IDENTIFICATION AND ASSOCIATION IS MORE IMPORTANT THAN PERFORMANCE MINUTIA WHEN IT SERVES TO PROVIDE A SUPERIOR USER INTERFACE.
While simple "paths" may have better performance than more abstracted file identification and tracking mechanisms, the user interface provided by the abstract mechanisms is worth the trade-off. The fact that more primitive operating systems do not "natively" support these abstractions is not an adequate reason to deprecate or abandon them.
Moreover, any performance penalties and historic limitations inherent in such file access abstractions should be eliminated, not by eliminating or decreasing the abstraction, but by creating new, more advanced implementations of these abstractions in Mac OS X."<hr></blockquote>
After that, it's all over but the shouting, IMO. But maybe some hard core developers would have specific API issues that they could expand on.
But from a user's perspective, people just want stuff not to break. Upgrade IE and the Dock suddenly has a question mark in it? Lame. I should be able to do what I do in Mac OS 9. Start downloading a file, then move the file while it's downloading? No problem! Start copying a large file and then 1) move the file, 2) rename the folder it's in, and 3) rename the volume the file is on? Hey, Mac OS 9 is right there with me. That, as Darth Vader said in that Arnie movie, is power
(ObNOA: Now you're playing with power!(tm) :-)
You mean welcome back, and I should be the one saying it to you
[quote]Glad to have someone as respected as you here.<hr></blockquote>
Bah, can someone just tell me if there'll be a new tower case at MWSF or not?
("I have three prototypes on my desk right now, one in the shape of a duck, one encased in a steel lemon...")
[Edit: Note that the lemon is sealed, meaning that we're sure to get "Aqua acceleration" at last! :eek: ]
[ 12-10-2001: Message edited by: John ]</p>
oh, and the steel lemon sounds REALLY GOOD!
see, the problem with Apple's new metallic line-up is no more hilarious kimkapsol posts saying that he is making the plastics right now!
What "skill" is required? The OS has the "skill." The user just has options (or can simply accept the defaults, whatever they may be).
[quote]Superior user experience sounds all kewl and neat, but to make it work right to make it superior. It's almost paradoxal.<hr></blockquote>
Nah, it's just "hard"
It says, it must be robust, expandable with high speed journalism, that is standardized.
The 4 great words of tech community. And half of them never come out right. It will be bickered, hacked, be bug ridden, and as I like to say, "Mircosofted"
Even with the imperfect results I'm sure technogy will emerge, in debatable quality.
But there would be more trade off along the way, and with it more options and "Skills' needed to handle it.
Realisticly. On something as a 'niche' system, "default" will never be enough in our increasingly big melting pot.
To accommodate it this, there is user customization process, like pc exchange(I guess). And that requires SKILL.
~Kuku
I don't mind to add an extension since I came from Windows world. Usually I keep it as a easily, quickly readable reminder of the nature of a file. But I would like to be able to choose : sometimes, I like no extension on a file and when I change things It begins to create mess...