Re: Files with a substructre should be directories.
"Friedrich W. H. Kossebau" <[email protected]> Sun, 26 May 2002 17:51:50 +0200
| Newsgroups | gmane.comp.kde.look |
|---|---|
| Message-ID | <[email protected]> |
Sven Niedner schrieb: > > Am Sonntag 26 Mai 2002 15:38 schrieb Friedrich W. H. Kossebau: > > > [NeXT Step] > > Great. Thanks for this information. So there is a reference to use when > > argumenting for this approach :) > > The point is: There are a lot of data formats that actually contain meta > data. You quote mp3 as one example. This approach in incompatible with the "a > directory is a file" concept. Yes. So one has to introduce a compatibility-layer :) On "our new" system these "conventionell" formats are not used. If we have to interact with outer systems that use those formats the data will be sent through the layer and transformed: Example mp3: -------------- our system: a mp3 file is a directory with - a file of type mp3-rawstream named "stream" - a file "title" of mimetype text/string - a file "artist" of mimetype text/string - a file "style" of mimetype text/string - a file "album" of mimetype text/string - a file "track" of mimetype text/string - a file "year" of mimetype text/string - a file "copyright" of mimetype text/string - a file "comment" of whatever mimetype. One could even extend this "format" and add a file "icon" or whatever. When about to transmit this file to someone outside a mp3-filter will pick the file "stream" and those for the id3-tag to compose the file in common mp3-format. -- Yes, would need a filter for all formats, but mostly it will be a composing of streams, so no great thing I guess. My only problem is right now: where to store the extended attributes / metadata? What are extended attributes / metadata, what aren't? Someone might want to have a comment for a mp3-file in rich-text-format. And add a comment to the comment like "better rewrite"... Help! Friedrich