Ian Hickson wrote: > On Tue, 16 Jun 2009, Greg Wilkins wrote: >>> is there any reason from a browser prospective to avoid the inclusion >>> of META-DATA in this kind of protocol? >> [...] >> >> I'm not sure if there are other objections - Ian? > > It would be best to ask browser vendors directly, but off-hand I can't > think of any reasons other than the necessary added complexity (parsing > the metadata, handling exposing it to scripts, defining all the error > handling to ensure bogus servers are handled predictably, etc). Note that I think the discussion of what should be exposed/changed in the API is a different one to the transport protocol. I think changing the API is something that can happen more easily over time than changing network infrastructure. I think trying to future proof and API for unknown future use-cases mostly leads to strange APIs, while future proofing transport protocols to future use-cases is good practise. For example, already the websocket protocol proposal has more capabilities than the API supports. With BWTP I'm proposing that this additional capability be taken to be equally capable as HTTP. >> Note that I would say that WebSocket also has meta-data. Just that it >> is fixed and cannot be overridden. For example the plain text UTF-8 >> datagram is the meta-data default for the sentinel framing of websocket. > > Insofar as framing is metadata, yes. I was really refering to an implied text/plain;charset=UTF-8 content type with no content-encoding. cheers
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.