Subject: enclosures: type and length

From: Lucas Gonze <[email-masked]>
Date: Wed, 13 Oct 2004 10:59:19 -0400 (EDT)

On Wed, 13 Oct 2004, Alex Kolesnichenko wrote:
> r> 4 The required content-type attribute is a bad idea in the first place.
> r> 5 The required content-length attribute should not be there.
...
> And
> 4 and 5 can help both user and software to choose the conditions when the
> file should be downloaded or simply shown as a link. I'd better made length
> attribute optional in order to make publishing of streaming content
> possible. The situation when client software has to roundtrip to server
> making HEAD queries for discovering trivial attributes is inacceptable. Even
> if content-type and length will be broken, the problem can be resolved in
> downloading process.

Why is it unacceptable?  What application requirements does that roundtrip 
affect?

I realize that inefficiency is bad in itself, however demonstrating that 
there is ineffiency is not so simple as wishing a more efficient 
technology existed.  The meaning of an enclosure is that this is an item 
to pre-cache, and the meaning of the type is that this is an item to 
pre-cache.  The type is redundant, so it does no work, and the type will 
be a large source of bugs, so it has a high cost.

> <enclosure>s are broken from the another side -- I cannot specify more than
> one <enclosure>. And, the worst, I cannot specify alternative <enclosure>s
> (ie. user could have a choice to download radio show in either MP3 record
> format or its script in DOC).

:) This is a playlist usecase!  See
http://gonze.com/xspf/xspf-draft-8.html#Usecases%20for%20playlists

The idea of syndicating playlists is right where I'm headed, and it's the 
reason I'm taking the trouble to deal with enclosures. See 
http://webjay.org/by/lucas_gonze/organism.xspf for a playlist which 
supports alternate IDs *and* the Atom modified/issued/id elements.  Those 
playlists could easily be converted to Atom, but they could also be 
considered feeds without any conversion.

- Lucas

---

From: Antone Roundy <[email-masked]>
Date: Wed, 13 Oct 2004 09:21:53 -0600

On Wednesday, October 13, 2004, at 08:59  AM, Lucas Gonze wrote:
> The meaning of an enclosure is that this is an item to pre-cache, and 
> the meaning of the type is that this is an item to pre-cache.  The 
> type is redundant, so it does no work, and the type will be a large 
> source of bugs, so it has a high cost.
"image/jpeg" means "pre-cache this"?  Silly me, I'd been interpreting 
it to mean that the enclosure was a JPEG image.

> The idea of syndicating playlists is right where I'm headed, and it's 
> the reason I'm taking the trouble to deal with enclosures.
So again I say, if you're playlist-handling application finds 
content-type to be too unreliable, go ahead and ignore it.  But there's 
no reason to assume that other applications find it equally problematic.