On 9/7/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
On Wed, 06 Sep 2006 18:29:35 +0200, Mark Baker <[EMAIL PROTECTED]> 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
application/xbl+xml.
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?
See;
http://www.w3.org/2001/tag/doc/mime-respect.html#external
Mark.
