- From: Mark Baker <distobj@acm.org>
- Date: Thu, 7 Sep 2006 10:11:14 -0400
- 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 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.
Received on Thursday, 7 September 2006 14:11:28 UTC