Linus Torvalds <[EMAIL PROTECTED]> writes: > In a graphical environment, the "icon" stream is a good example of this. > It literally has _nothing_ to do with the data in the main stream. The > only linkage is a totally non-technical one, where the user wanted to > associate a secondary stream with the main stream _without_ altering the > main one. THAT is where named streams make sense.
I think that the "icon" argument for named streams is a silly argument, since different users may want to have different icons for the same file. Say that I want /usr/bin/emacs to have the enterprise icon and someone else wants the gnu head icon. And besides, root owns the file anyways, so neither of us mortal users should be able to add a stream to it. Another reason for named streams that usually crops up is the ability set a "preferred application" for a certain file, so that when I double click on a document I want to open it with antiword instead of openoffice. But the same contra-argument applies here, different users have different preferences. I can see the argument for having the equivalent of Content-type or Content-transfer-encoding as a named stream though. /Christer -- "Just how much can I get away with and still go to heaven?" Freelance consultant specializing in device driver programming for Linux Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se
