I agree with #2 also. It's not be unimaginable that the ideal Docster would
serve as its own database program, keeping track of files on the hard drive
and doing some sort of monitoring of files "out there". If this were the
case, relying on file types or any attempt at a comprehensive file names
system would be silly.
Nathan Williams
nathanw@...
> -----Original Message-----
> From: Daniel Chudnov [SMTP:daniel.chudnov@...]
> Sent: Tuesday, October 10, 2000 12:29 PM
> To: Nathan Williams
> Cc: oss4lib-docster@...
> Subject: file types...
>
>
>
> On Tue, 10 Oct 2000, Nathan Williams wrote:
>
> truly implemented ID3 in the sense of practical usability. Napster is
> still
> totally on filenames. This would obviously not be sufficient for
> Docster.
> Even though metadata has been discussed in conjuction with Napster, the
> protocol and program themselves are good representations of distributed
> file
> sharing; as far as I've seen, their metadata implementation thus far is
> pretty nil.
>
> Being built from day one around the mp3 spec, napster has the advantage of
> self-describing files even if, as you point out, id3 searching isn't too
> great. So we have two options:
>
> 1) defining some sort of document wrapper a la ariel, and using mime-types
> to distinguish contents' file types;
>
> 2) being file-type neutral, and defining a corollary contents-list
> structure that can associate local files with some sort of lightweight
> metadata holder which includes the biblio info and file pointers. an
> advantage is that we might use something like the dienst/openarchives work
> to report out of these holders.
>
>
> Me, I'd vote for #2, because yknow, who needs another file type, but
> that's just me. It looks like the m3u files that xmms (and presumably
> winamp and the like) just use a file list. Has this been extended
> anywhere?
>
>
> -dc
>
|