[whatwg] BWTP for WebSocket transfer protocol

On Wed, Aug 12, 2009 at 1:10 AM, Greg Wilkins<gregw at mortbay.com> wrote:
> Jonas Sicking wrote:
>
>> I agree we should use the experiences from HTTP. However it seems like
>> we have different experiences.
>>
>> For example mime-types in HTTP have a very troubled record. Look at
>> Adam Barth's draft [1] for what browsers are forced to do to stay
>> compatible with the web.
>
> Indeed. ?However I would argue that a lot of that problem is probably
> the result of the initial HTTP protocol not supporting content types,
> so that browsers started infering type from URL extensions etc.
> So when a proper mime-mechanism was finally provided, it was too
> late as bad practises were entrenched and remain so to this day.
>
> I would hate to see a new protocol repeat this mistake and
> start without support for content-types.

I don't think this was due to initial mistakes as the problem keeps
repeating. It's not just that many times there is no appropriate
mimetype to use (such as the fonts example). I think the judge is
still out on if we'll be successful in enforcing mimetypes on video.

>> So while I agree that we should look towards existing protocols, we do
>> need to be honest about what has been successful and what hasn't, and
>> not just assume that of existing protocols do something, it's a good
>> idea.
>
> I totally agree.
>
> I think we should start with existing protocols, slice away the
> capabilities that are not used and then build from there.

I'd rather not debate about which process should be used to get to a
good protocol. I'd rather debate concrete proposals.

>>> Example proposal to improve websocket protocol that
>>> was rejected:
>>>
>>> Greg Wilkins wrote:
>>>>> It would be great if the websocket proposal could include
>>>>> standard definitions for mime encoded datagrams.
>>>>>
>>>>> Current frame types are:
>>>>>
>>>>> ? 0x00 ?- sentinel framed UTF-8 message
>>>>> ? 0x80 ?- length framed binary data.
>>>>>
>>>>> I'd like to see two additional frame types supported
>>>>> by default:
>>>>>
>>>>> ? 0x01 ?- sentinel framed UTF-8 encoded MIME message
>>>>> ? 0x81 ?- length framed MIME message.
>>>>> ....
>>
>> If we want mime-support this seems like a good proposal. Except I
>> don't understand the point of having the mime header optional? If
>> someone wants to send something without a mimetype it seems like the
>> other frame types cover that.
>
> The mime head was not optional, it was just proposed that an empty
> header (CRLFCRLF) would be legal. ? ?You don't really want to have to
> be forced to change framing type just because you don't have any metadata

The proposal specifically said "The header is optional and terminated
by CR LF CR LF". Anyhow, I don't think it's an important issue. I'm
also wondering why terminate the mimetype with "CR LF CR LF" rather
than simply space or a null character?

>> I'm curious to hear what you consider the advantages of this over
>> simply transmitting for example JSON over a "sentinel framed UTF-8
>> message" frame? I.e. can you describe an application that would send
>> JSON using the above proposal.
>
> It would be difficult to transport some media types over
> JSON on a sentinel framed UTF-8 message. ? For example image/jpeg
> would not be efficiently sent in JSON.

I think you are misunderstanding my question, so let me try over from
the beginning:

The proposal proposed that the API could use a separate notification
mechanism when JSON data was transmitted. So I take it that it is
imagined that someone will want to submit JSON data for *something*
using the wire protocol (in addition to other types, like text/xml and
image/png)

Additionally, it seems like the proposal claims to add some value when
transmitting JSON data using the new 0x01 frame type over transmitting
JSON data using the existing 0x00 frame type.

So, can you describe an application which takes advantage of this
added value. I.e. an application that transmits JSON, and that would
not be put at some type of disadvantage (slower, harder to implement,
impossible to implement etc) if it couldn't use the new 0x01 frame
type.

I hope that better explains my question?

/ Jonas

Received on Wednesday, 12 August 2009 02:16:07 UTC