Re: Media types and rss (was Re: Using dc:language vs language)

Hey Lucas,

On 6/12/07, Lucas Gonze <[email protected]> wrote:
>
> On 6/11/07, Charles Iliya Krempeaux <[email protected]> wrote:
>  > Consider a video that is made of up 2 video clips.
>
>  Another way of tackling this --
>
>  Both A and B are media HTTP links encountered by an RSS user agent
>  with good support for HTTP caching.  When the RSS user agent initially
>  encounters these links it fetches them.  A has a cache expiration date
>  far in the future.  B has an cache expiration date. When the user
>  agent is requested by the user to render them, it checks the
>  expiration and finds that A can be served from cache but B has to be
>  re-requested.

I agree that HTTP provides some useful semantics through the HTTP
"Cache-Control" header (as well as with the ETag and Last-Modifed
mechanisms... with the conditional GETs)... however, it would be nice
to get rid of that initial download, if possible, IMO.

The reasons being... #1: to save on bandwidth... and #2: to get more
accurate measurements of impressions.

With #1... people have to pay money for each extra download... so
designing it in a way that minimized cost would be a good thing I
think.

Also with #1... more downloads can increase the "stress" on the
servers... which could give some publishers problems.

With #2... I think we'd like to be able to say that usually... a
"download" equal a "view".

Also with #2... and this would be important in the advertising
world... if you were selling on a CPM basis, you don't want extra
downloads that nobody watches (because advertisers won't want to pay
for those).  (I.e., selling on the basis of the "impression".)


If we wanted to stick to HTTP... which would be a good thing IMO...
then what I think we'd need is a (new) "conditional GET" where we can
say something like...

    Return the contents of this "resource" only if I can cache it for
"X" amount of time.

Where "X" would be a very large number.

I'm tempted to say use the existing "If-Unmodified-Since" HTTP request
header, but give it a date far in the future.  But I don't know how
existing HTTP servers would handle that.


Also... I think "hinting" in markup can be useful as well.

So... perhaps a way of adding info about the "volatility" of a
resource would be useful.  Like...

    <enclosure volatile="yes" href="..." />

    <enclosure volatile="no" href="..." />

Note I used the fictitious "volatile" attribute (instead of something
that mimics the HTTP Cache-Control header) just to keep things
simple.... to keep the "Simple" in RSS :-)

An <enclosure> with volatile="yes" would mean do NOT prefetch... but
wait until the last minute to download it.

An <enclosure> with volatile="no" would mean do prefetch.



See ya

-- 
    Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>


                  All the Vlogging News on One Page
                         http://vlograzor.com/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-public/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rss-public/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/