Alexander G. M. Smith wrote:
Jeremy Powers <jpowers@xxxxxxxxxx> wrote on Sun, 06 Jan 2002 18:34:47 -0800:
And I may just be crazy, but it occurs to me that file types should refer to the specific collection and interpretation of attributes, rather than one main data chunk. Pretty much all file types require some kind of meta-data and organization - what is to keep this from being done with attributes? (besides speed, complexity, ect...)
Currently attributes themselves have a simple type, defined by a code that specifies int-32, int-64, float, double, string, MIME-string or boolean. Might also be a few date and time formats too. The type of a file is stored as a MIME string in an attribute called "BEOS:TYPE". If you wanted to label attributes with a type (rather than using codes), that would mean having an attribute on an attribute. Or perhaps make the list of codes extensible - a global dictionary would tell the application that the attribute with code 42 is type audio/x-mpeg. But then what would the type of the overall "file" be? Currently the overall type is the type of the main data, which could be considered an attribute with no name.
ID3 tags on mp3s are a good example of this. Stick the sound data in one (probably main) attribute, then the name, artist, date, etc in others. Conversion from flat file to attributed would be a simple task. File types that are better represented as one stream would be defined as such, but others gain much in organization.
Hmmmm. Need to think about this - full types for attributes or just for the overall "file" (which actually contains data and attributes).
- Alex
