[annodex-dev] Timed URI seeking without mod_annodex

Andre Pang Andre.Pang at csiro.au
Mon Feb 21 16:47:32 EST 2005


On 20/02/2005, at 11:40 AM, Conrad Parker wrote:

> What we've done is designed a system that works within the web
> infrastructure:
>
> 	* one URI per resource
>
> 	* HTTP GET to retrieve resources
>
> 	* The (optional) ability to retrieve CMML via the existing HTTP
> 	Accept: request header

All true -- except that you need a customised Web server to be able to 
handle it.  This makes it compatible with the HTTP and Web protocols, 
but it is not compatible with the majority of Web servers out there on 
the Internet day.

> You're proposing to introduce a new
> mechanism which requires a more complex negotiation followed by a 
> sequence
> of HTTP/1.1 Range requests. A mechanism which has no equivalent to
> "Accept: text/x-cmml". A mechanism which puts an extra barrier up to
> crawlers and other clients (requiring smarts in retrieval code, not 
> just
> in content scanning).

Well, all the ideas for caching that we've talked about so far use 
pretty much the same HTTP negotiation mechanisms -- the server replies 
with the appropriate byte ranges in response to the timed URI, which 
the client then requests from the server to feed the caches.  I think 
the scheme I'm discussing right now and the caching scheme involve the 
same extra barriers that you speak of.

> You fail to realize that this new mechanism is not optional. If some
> nontrivial number of sites were to use it, then anyone wishing to
> retrieve annodex media *must* use it, in perpetuity.

I do not fail to realise that the new mechanism is not optional; on the 
contrary, if we were to support this, I would advocate it as the 
primary way of getting Annodex content.  Why enforce the need for 
server-side timed URI handling when clients are perfectly capable of 
handling it themselves?

> If we were to design some kind of "serverless" solution to this
> problem which you are presupposing, it would be contrary to the
> mechanisms we have designed so far. It should replace the existing
> mechanisms, for if we allow both the existing and your proposed,
> mechanisms, then we require smarts in all clients, and also encourage
> smarts in servers. Let's put the simplicity in one place -- I say
> clients, you say servers, let's battle that out.

I do not see this as a replacement for server-side seeking, but as a 
complement.  Dynamic recomposition is impossible without server-side 
support, for instance.  If the server understands Annodex and 
manipulate it, then by all means, use the server-side support.  If the 
server does not understand it, at least the client can still use one 
extra feature of Annodex they would not have been able to otherwise.  I 
never intended to replace server-side functionality, merely complement 
it.

> What irks me is that you're presupposing a problem, and suggesting a
> half-baked solution that denies most of the features that we've been
> working towards for the past few years -- with the exception of the
> features you've been concentrating on for the past few months, ie. 
> those
> concerning a media playback client.

My "half-baked solution" is only so if you think of it as a replacement 
for server-side support, which it's not.  As I said, it's a complement 
to it.

> As Zen pointed out, most existing hosting providers, the ones you are
> worried about, don't allow mp3 and general media streaming due to 
> bandwidth
> constraints. If you're going to talk about server-side blockers to
> take-up, bandwidth is the real issue. And seriously, Annodex is a bonus
> for hosting providers, as it is designed to cleanly avoid unnecessary
> bandwidth by only serving out the requested content, in one hit.

I suspect that most providers don't provide MP3 or general media 
streaming primarily because the majority of people simply don't need 
that feature, not because of bandwidth constraints.  I am not 
attempting to address the high-bandwidth, high-speed hosting providers 
with this scheme: for them, installing an extra Apache module is likely 
a no-brainer, especially compared to the other server-side streaming 
solutions around (such as a Windows Media Server, or QuickTime 
Streaming Server).  I'm trying to provide support for the casual Web 
user: people like you and me who don't have gigabytes of content to 
serve out, but want to host a small amount of Annodex content on their 
webpages.  I can't do this with my homepage today -- which is a tad 
disappointing considering we invented all this technology, no?


-- 
: André Pang (x4180)
: Software Engineer, Networked Media : CeNTIE



More information about the annodex-dev mailing list