W3C home > Mailing lists > Public > public-appformats@w3.org > September 2006

Re: XBL media type?

From: Mark Baker <distobj@acm.org>
Date: Thu, 7 Sep 2006 10:11:14 -0400
Message-ID: <c70bc85d0609070711q66a743efpe71f1815d67262fc@mail.gmail.com>
To: "Anne van Kesteren" <annevk@opera.com>
Cc: public-appformats@w3.org

On 9/7/06, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 06 Sep 2006 18:29:35 +0200, Mark Baker <distobj@acm.org> wrote:
> >> I don't really see what you mean with the efficiency argument
> >
> > I mean that I want to be able to hand off the incoming data stream to
> > the correct processor at the earliest possible time to minimize
> > latency, and since the media type arrives before the root namespace -
> > and in plain text form (not encrypted or compressed) - it's more
> > efficient to do so using its value.
> Since it has to go through an XML parser regardless (at which point you
> can easily make that check) I don't see the point.

Right, the parser doesn't matter.  But in the application/xml case,
there is a wait time between when the value of the Content-Type header
is received and when the processing of the data stream begins.  You
can't get that time back.  And there is no wait with

Given that XBL will largely be used for user-facing content, that
means a longer wait for users.  It's probably not much in a
high-bandwidth desktop scenario, but in a mobile context where both
processing speed and bandwidth is (relatively) low, it could be
noticeable.  More importantly, it's unnecessary.

Moreover, the cost of using a specific media type is, AFAICT,
completely in the registration process, which is a one-time (if all
goes well 8-) fixed cost.

> This isn't really an issue for XBL. The format expected when it's
> retrieved is XBL and if it's not it will simply yield in an error.

Which severely limits evolvability.  Are you sure there won't ever be
a competitor to XBL that the industry might want to migrate to?



Received on Thursday, 7 September 2006 14:11:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC