>From [EMAIL PROTECTED]
>On Thu, May 10, 2001 at 03:06:44PM -0400, Benjamin Coates wrote:
>> Content-Type is how the client decides which viewer to pass the data on to.
>> Clients are unlikely to do anything at all with things like "Description" 
or
>> "Publisher" or "Title".  This is the sort of thing that would be useful
>> *before* you download the CHK, like in an index or something, but putting 
it
>> into the CHK itself means you have to download the whole file to get the
>> subject (for example).

>I don't have the ability to decode mpegs, it would be nice to know if 
something
>is an mpeg before fetching the whole bloody file.

I suppose a redundant content-type tag in whatever indexing/searching system 
you are using would be useful, and harmless enough.  But I don't see the 
benefit in adding dublin-core syle metadata to the CHK... what would you do 
with it?

>Any argument you make for Content-Type will apply to any other generalized
>metatdata.

Here, however, I have to disagree.  I don't think 'generalized metadata' is a 
very useful concept, there is metadata you need to use the data (content-type, 
content-encoding, blah...) and metadata used to find or index the data.

>Just because -your- particular pet application is browsers and other 
web->centric stuff doesn't necessarily make it special in any one else's view.

Fair enough, but as a practical matter, I don't think many (and by no means 
all) applications involve being able to identify data without any context at 
all.

>(for instance)
>
>I just want to get the damn data in and out of Freenet, I expect that I'll
>know what it is and what's going to be done with it *before* it's inserted
>or fetched.
>
>What the hell do I care about Content-Type?
>
>David Schutt

How do you know what it is before you request it (or afterwards, in the 
absence of a content-type tag or the equivalent)?

--
Benjamin Coates


_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl

Reply via email to