Re: XBL media type?

On Thu, 07 Sep 2006 16:11:14 +0200, Mark Baker <distobj@acm.org> wrote:
>> 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.

I don't understand that "wait." Things are solely based on  
namespace-dispatching not MIME dispatching.


> 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.

See above.


> 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.

If it's not necessary it will confuse people for ages. Which means a lot  
of cost as they could be doing useful work instead of getting confused  
about optional things.


>> 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?

If it's optional you have this issue anyway. It would be nice if you made  
it more clear what you're proposing.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 7 September 2006 14:52:00 UTC