[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