*** Metadata petition! Please read!

This is important so 'Bump!'

Apple should hire Siracusa!

[quote]Originally posted by Carbonide:
<strong>Apple should hire Siracusa!</strong><hr></blockquote>

He certainly would be a great guy to have working there... but we need sensible, articulate critics on the outside too!

He may be more valuable to the Mac platform working from outside of Apple.

[quote]Originally posted by Carbonide:
<strong>Apple should hire Siracusa!</strong><hr></blockquote>

AND Tog.

What's with the praises?

At this point the only reason Siracusa idea is petitioning is BECAUSE he's of the minority in opinion.

Apple seems to have rewrote it because of the developer input.

While this may still be a good way, developers obviously have other ideas. And they should have more sway than Siracusa in this sense since they actually develop for it.

Having Siracusa aboard, maybe, maybe not. Outspoken and popular doesn't nessarity equal what's inside Apple.

This is a reason why petitions don't always work. They many times don't know all the facts.

Something so technical should be more logical then emotional. Something other than praises please.

~Kuku

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.

[quote]At this point the only reason Siracusa idea is petitioning is BECAUSE he's of the minority in opinion.<hr></blockquote>

I don't see any support for that assertion. Have you been participating in the discussions on the various developer mailing lists on this topic?

[quote]Apple seems to have rewrote it because of the developer input.<hr></blockquote>

Were you at the last WWDC? "Despite" is a lot more accurate than "because of" in that sentence.

[quote]While this may still be a good way, developers obviously have other ideas.<hr></blockquote>

See above.

Ker-bumb.

I was really skeptical about this until I actually read his proposal. It seemed to me that the direction Apple was taking was the right one because of the interpolarity with Windows and other OS' that it offers, but reading his proposal, he doesn't sacrifice that interpolarity, but rather expands it, ultimately making the Mac the ideal platform for file compatibility with *all* systems. Just read his <a href="http://siracusa.home.mindspring.com/john/articles/metadata.html" target="_blank">proposal</a> and you'll see what I mean.

[quote]


I don't see any support for that assertion. Have you been participating in the discussions on the various developer mailing lists on this topic?

quote:

Apple seems to have rewrote it because of the developer input.


Were you at the last WWDC? "Despite" is a lot more accurate than "because of" in that sentence.
<hr></blockquote>


From <a href="http://www.xlr8yourmac.com" target="_blank">http://www.xlr8yourmac.com</a> news page.

"Hi, you're maybe aware of the fact, that Apple proposed to replace the type/creator etc metadata completely by the usage of filename extensions in OSX. They did so in their Technical Note 2034 (which has been redrawn lately due to the overwhelming criticism they received from their developer community). Apple tells us, that they're going to adapt the TN based on our feedback in the developer mailing lists. "

I see Overwhelming as a majority.

~Kuku

[ 12-08-2001: Message edited by: Kuku ]</p>

I dunno. After reading Siracusa's proposals it sounds as though his way would make things more complicated for the user than the way things are now.

Not saying there isn't room for improvement (there always is). But his proposals don't seem all that great. Who wants all those warnings popping up everytime they name, or don't name, something?

I can just see my mom calling and saying she's got a message on her screen that she has this on her screen:
Warning: "copying files with a particular metadata representation to a volume whose
metadata abilities are either unknown (or known to be limited), or when files are transferred via a protocol that does not support Mac OS X's native set of metadata".

To which I would reply:
"Files that arrive on the system via a web browser (or any other network service or disk) could (optionally, or by default) be brought up to "native" metadata standards by extrapolating and filling in any missing metadata according to the per-user mapping tables described above..."

No thanks. The thing is, I don't know anyone that has had any actual problems with the way things are. Philosophically, maybe. In practice, no. Not saying its currently impossible to run into a physical problem, I just haven't heard about it.

I don't know anyone who couldn't figure out what the .doc document was just because it had that suffix, nor has anyone been unable to open mail just because you can configure your Mac to see .app at the end (I don't see .app in my column view). And the average user shouldn't be messing with .plists either, should they?

To be honest, I just don't see what all the fuss is about. Is it mainly a philosophical complaint?

[ 12-08-2001: Message edited by: seb ]</p>

It is too bad that type/creator codes are gone though.

Ok Starfleet, I think I see your point. However, in OS 9 you didn't have any way of knowing if an app was an app by an extension either. And if you do a 'get info' on something, or look at it in a finder window you'll see it as "type: Application". Of course, if the file is in an email, as you mentioned, one wouldn't readily have those methods of identification at their disposal.

I was mistaken in thinking you guys didn't want to see the .app on the end. Are you saying the problem is that you don't, or that you can't? Or is that you can have more than one extension and that one is misleading and/or irrelevant. From what I can tell by reading the proposal the basic problem lies in only using file extensions as the only means of metadata. Is that right?

I'm not a developer, so perhaps I shouldn't even be throwing my .02¢ in. But, on the other hand, if you can convince me then it should be easy to convince those more "in the know".

And yes, I did read the proposals, but you see what I got out of it, or rather, what I didn't and even though I'm not a developer I'm not some ignorant dummy either. I guess I just don't quite grasp what the big deal is. Maybe I should just let you guys worry about it.

[quote]
I just have to ask: have you completely read Siracusa's articles and proposal to Apple? If not, I really don't think you should be making comments about them.

I'd like to know your stance on this issue, not on whether on not Apple made this move because of "overwhelming criticism" of type/creator codes.

Do you think file extensions are really the best way to go now? Do you disagree with Siracusa's proposal? If you do disagree, why? Do you have a better solution?
<hr></blockquote>

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.

To the petition itself though. I for one do not fully understand it myself(Know your betters). Simply because I don't assume to know the whole story here. And not going to go researching all over the net either. Things that come to mind is.

Compability- How will apps interact with this high level metadata? I assume it's a joint effort to get this to work. Developers not just apple will have a role in this in apps and files they produce and read. On a simple example, sit does compressed typle/creator while .zip doesn't. If all metadata is going to be stripped, even replacing it again and again doesn't always come out right. Unix and Linux files notoriously become recognized as text/ascii in our old classic metadata. BIG problem in the case of .img files.

Grey area- The petition only slightly mentions carbon,cocca and unix. How well will this incorporate, how hard will it be. How much over head? How long? How well made? How much bugs? How much, "We're sorry it will be fixed/implemented in the next release". An idea is only good if it's realistic.

To sum up this long winded, no one will read this far, post.

-In Practice- Does the end justify the means? Basically engineering is about trade-offs. I'm sure apple developers knew that, that was why they started rewriting stuff(Even now apple proposes some more weird stuff on this issue)

~Kuku

[quote]Not saying there isn't room for improvement (there always is). But his proposals don't seem all that great. Who wants all those warnings popping up everytime they name, or don't name, something?<hr></blockquote>

Not me. That's why many parts of the proposal are specifically designed to eliminate such warnings--warnings that exist in Mac OS X right now. Go on a renaming spree in the 10.1 Finder and see for yourself; there are some real winners in there. "This file may become a folder" anyone? :-)

Under the proposed system, an email attachment called "resume.doc" sent to a Mac OS X system from a PC user would be "promoted" to a proper set of Mac OS X metadata (whatever that may be at any given time) when it arrives on the system, subsequently enabling the Mac user to change the file name to whatever he wants without any fear of warnings. And if the "smart hiding" feature was enabled on that Mac OS X system (something allowed for by the proposal), it would be nearly impossible for your mom to accidentally remove that ".doc" extension.

[quote]I can just see my mom calling and saying she's got a message on her screen that she has this on her screen:
Warning: "copying files with a particular metadata representation to a volume whose metadata abilities are either unknown (or known to be limited), or when files are transferred via a protocol that does not support Mac OS X's native set of metadata".<hr></blockquote>

First, your mom would never see that warning if her Mac was configured according to the current 10.1.x defaults (which it should arguably be, out of the box).

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.

[quote]To which I would reply:
"Files that arrive on the system via a web browser (or any other network service or disk) could (optionally, or by default) be brought up to "native" metadata standards by extrapolating and filling in any missing metadata according to the per-user mapping tables described above..."<hr></blockquote>

See above. You wouldn't have to reply anything because she'd never call you. She'd click "okay." And she'd only have to make that click if she'd changed her Mac OS X configuration from the default "mom mode." The parts of the proposals you're citing describe things OS could do for you, not things that the user would have to be aware of and do for him/herself.

[quote]he thing is, I don't know anyone that has had any actual problems with the way things are. Philosophically, maybe. In practice, no. Not saying its currently impossible to run into a physical problem, I just haven't heard about it.<hr></blockquote>

Maybe you should read some of the comments accompanying the 7,000+ petition signatures.

[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.

I hope my earlier reply makes more sense now.

[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.

[quote]Originally posted by John:
<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

[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.

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.

[ 12-09-2001: Message edited by: Fluffy ]</p>

The anti-metadata petition misses the point.

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>

[quote]Originally posted by Amorph:
<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.

It does bring up a good point. Though.

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

[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

(ObNOA: Now you're playing with power!(tm) :-)

[quote]Welcome to the forums, Mr. Siracusa.<hr></blockquote>

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>

[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>

Nah, it's just "hard"

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.

~Kuku

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...