Subject: [hybi] How much metadata?

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 3 Aug 2010 08:46:31 +0800

Pick one:

None

  Each frame is opaque to intermediaries.
  The client and server both know what to send and what to expect.

Text/Binary flag

  Each frame is marked as being text or binary.
  Provides the API with decoding information.
  The client and server know about content.

Content-Type

  Each frame can be marked with a content-type.
  Undecided whether this is a separate frame or not.

Text/Binary and Content-Type

  For completeness: a combination of the two.
  (Observation: might be fun to have a text frame that is marked as application/octet-stream.)

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 3 Aug 2010 11:15:15 +1000

>  The client and server both know what to send and what to expect.

I don't think this is practicable if we are to support binary types, because
people will want to send polymorphic binary messages (eg image/gif,
image/jpg, etc), so they will need to send at least content-type.    If we
don't provide at least a standard extension for this, then the wheel will
constantly be reinvented.

>  The client and server know about content.

I think this is orthogonal to meta-data and really is just an indicator if
the packet is for the text API or the binary API.  It could be derived from
meta-data, but that would make meta-data support a less optional part of the
specification.  So I think this flag is reasonable to have regardless of
what is decided for meta-data.

>  Each frame can be marked with a content-type.

Why just content-type?  Surely any old MIME header that relates to content
should be able to be sent if need be.

>  Undecided whether this is a separate frame or not.

I think it should be a separate frame type (see other thread for a proposal
to make it part of the same message, but in a different frame).

However, I'm open to other suggestions including punting it to an extension
mechanism, so long as that extension mechanism is well enough defined that
we know it can be supported efficiently.

> application/octet-stream.)

I think we should say that if the frame is marked as text frame, then it is
just utf-8 text and can have no other meta data.
If we allow meta-data with the text frames, then we open ourselves to such
contradictions.

cheers

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 03 Aug 2010 10:15:03 +0900

First, I think calls such as the one below should be left to the chairs.

As for myself, I think that the text/binary distinction is very 
important (as explained by Maciej, myself, and others). This should be 
present in the 4-week version (well, actually there we might be okay 
with text only). If we can figure how Content-Type fits in with this 
distinction, then I have nothing against adding Content-Type (in the 
6-month version).

Regards,   Martin.

On 2010/08/03 9:46, Thomson, Martin wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 3 Aug 2010 10:05:07 +0800

> First, I think calls such as the one below should be left to the

'twas only a method of making a point.  I did not intend to imply anything other than the point that this is all metadata.

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 02 Aug 2010 19:06:10 -0700

+1

On Aug 2, 2010, at 6:15 PM, Martin J. Dürst wrote:

> As for myself, I think that the text/binary distinction is very important (as explained by Maciej, myself, and others). This should be present in the 4-week version (well, actually there we might be okay with text only). If we can figure how Content-Type fits in with this distinction, then I have nothing against adding Content-Type (in the 6-month version).
> 
> Regards,   Martin.
>

---

From: Dave Cridland <[email-masked]>
Date: Tue, 03 Aug 2010 09:20:39 +0100

>   The client and server know about content.

Just a side-note, but I did wonder whether the same argument (of API  
supplying a known object) applies to XML as well. It seems to me that  
there are three likely contents:

- Text, which can be encoded as UTF-8.
- XML, which can be serialized and encoded as UTF-8.
- JSON, which can be serialized and encoded as UTF-8.

... and then binary gloop.

Now, obviously all three "interesting" payload types could be handled  
as text and the script code in the browser left to decode them based  
on domain knowledge, but it seems to me that if signalling is useful  
to allow lower levels to decode UTF-8, it may be useful for decoding  
XML and/or JSON, too.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 03 Aug 2010 10:26:42 +0200

On Tue, 03 Aug 2010 10:20:39 +0200, Dave Cridland <[email-masked]>  
wrote:
> Now, obviously all three "interesting" payload types could be handled as  
> text and the script code in the browser left to decode them based on  
> domain knowledge, but it seems to me that if signalling is useful to  
> allow lower levels to decode UTF-8, it may be useful for decoding XML  
> and/or JSON, too.

Since there is JSON.parse and DOMParser we should probably only add  
dedicated support if people end up using XML and JSON a lot. But adding  
more frame types along the way is the plan, afaik.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Dave Cridland <[email-masked]>
Date: Tue, 03 Aug 2010 10:18:05 +0100

On Tue Aug  3 09:26:42 2010, Anne van Kesteren wrote:
> On Tue, 03 Aug 2010 10:20:39 +0200, Dave Cridland  
> <[email-masked]>  wrote:
>> Just a side-note, but I did wonder whether the same argument (of  
>> API  supplying a known object) applies to XML as well. It seems to  
>> me that  there are three likely contents:
>> 
>> Now, obviously all three "interesting" payload types could be  
>> handled as  text and the script code in the browser left to decode  
>> them based on  domain knowledge, but it seems to me that if  
>> signalling is useful to  allow lower levels to decode UTF-8, it  
>> may be useful for decoding XML  and/or JSON, too.
> 
>  dedicated support if people end up using XML and JSON a lot. But  
> adding  more frame types along the way is the plan, afaik.

Right, I have no preference as to whether we should, or should not,  
and no knowledge to inform me.

I'm really only interested in knowing whether this is worth doing -  
is there a (significant) performance penalty (in most browsers) for  
calling these in the event handler versa having the browser decode  
prior to the event being triggered?

 From a protocol design standpoint, the answer is interesting,  
because if these kinds of decodes should be done prior to the event  
being triggered, then "payload type" is worth separating out.

Dave.

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 03 Aug 2010 11:26:51 +0200

On Tue, 03 Aug 2010 11:18:05 +0200, Dave Cridland <[email-masked]>  
wrote:
> Right, I have no preference as to whether we should, or should not, and  
> no knowledge to inform me.
>
> I'm really only interested in knowing whether this is worth doing - is  
> there a (significant) performance penalty (in most browsers) for calling  
> these in the event handler versa having the browser decode prior to the  
> event being triggered?

Parsing is not a very big operation, but it is certainly faster if the  
browser does it internally and more convenient for the developer.

> From a protocol design standpoint, the answer is interesting, because if  
> these kinds of decodes should be done prior to the event being  
> triggered, then "payload type" is worth separating out.

Right, I understand that. However, I do not see why that needs to be  
separate from the "frame type". It seems a single byte is sufficient.

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 03 Aug 2010 12:05:02 -0700

On Aug 3, 2010, at 2:26 AM, Anne van Kesteren wrote:

> On Tue, 03 Aug 2010 11:18:05 +0200, Dave Cridland <[email-masked]> wrote:
>>> Since there is JSON.parse and DOMParser we should probably only add dedicated support if people end up using XML and JSON a lot. But adding  more frame types along the way is the plan, afaik.
>> 
>> Right, I have no preference as to whether we should, or should not, and no knowledge to inform me.
>> 
>> I'm really only interested in knowing whether this is worth doing - is there a (significant) performance penalty (in most browsers) for calling these in the event handler versa having the browser decode prior to the event being triggered?
> 
> Parsing is not a very big operation, but it is certainly faster if the browser does it internally and more convenient for the developer.

I don't think there is a meaningful performance advantage to the browser doing XML or JSON parsing internally vs. doing it in JS, using DOMParser or JSON.parse. Any savings would be miniscule compared to the cost of parsing. There is a slight convenience advantage.

Regards,
Maciej

---

From: Jack Moffitt <[email-masked]>
Date: Tue, 3 Aug 2010 17:22:14 -0600

> I don't think there is a meaningful performance advantage to the browser doing XML or JSON parsing internally vs. doing it in JS, using DOMParser or JSON.parse. Any savings would be miniscule compa…

XHR does the parsing for you (at least for XML), so there is an
argument to be made for consistency there.

Most everyone these days is using libraries where this is abstracted.
Personally, I'd rather have the option to get the data as a DOM tree,
a JavaScript object, or a giant string.

No matter if the user does the parsing or the browser, the content
type of the message will need to be known. jQuery is already full of
crazy heuristics to detect HTML content which people trip over all the
time. Let's not force that situation if we don't have to.

jack.

---

From: Joshua Bell <[email-masked]>
Date: Tue, 3 Aug 2010 17:52:02 -0700

> a JavaScript object, or a giant string.

I feel this is a slippery slope leading to turning a WebSocket frame into a
complete HTTP request/response.

Since WebSockets is message based (to fit the asynchronous processing model
of JavaScript), the most likely code is going to look like (borrowing from
the API spec):

var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onmessage = function(event) {

    // yay, we got a message from the server!
    var data = event.data;

    // now... what do we do with it?
};

We can probably enumerate the "what now?" cases:

* The server only sends you one type of message; you dispatch them all
identically (e.g. it's a line of text in a chat room; you simply append to
some display)

* The server is synchronously responding to a specific request you just made
(i.e. you're emulating COMET over WebSockets) with a body of data. In that
case, you know what to do with it since you just requested.

* The server is asynchronously sending you data which you need to reason
about before handling.

The last is IMHO going to be the most common, and is obviously the general
case. At the next level of detail, the data is either going to be content
(image data, DOM fragment, textual or structured data, etc) or a
service-specific event or some sort of combination. How you determine what
this is obviously needs to be sent, and your options are:

* We extend the WebSockets framing model to allow this sort of metadata
(content-type, content-encoding, content-disposition, ...) in the frame
header; or
* We keep the WebSockets framing model minimal and let the application
decide

The current WebSockets protocol and API lean towards the latter, and I
agree. I believe that the vast majority of the WebSocket JavaScript handling
code will look like this:

var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onmessage = function(event) {

    // yay, we got a message from the server!
    var data = JSON.parse(event.data);

    // now we can reason about structured data in a service specific way
};

If your service needs to send various content types you can design a
protocol of the form:

{ "content-type": "text/html", "body": "Twas <b>brillig</b> and the
<i>slithy</i> toves..." }

But is more likely to be something like the following which gives context so
the client can reason about what to do with the content it has suddenly
received:

{ "event-type": "text-chat", "from": "alice", "content-type": "text/html",
"body": "Twas <b>brillig</b> and the <i>slithy</i> toves..." }

To put the content type into the framing mechanism (other than to
distinguish binary/text, which I've argued before is necessary if we want to
get implementations out soon but support binary data ever) seems unnecessary
to me. Unless you're doing a trivial service (e.g. streaming update blobs
down, be they plain text or DOM fragments or bitmaps) you need a more
generalized metadata mechanism, and one is trivially easy to construct in
the browser.

Alternately, we take this to the slippery extreme and allow arbitrary
headers on a frame. And thus we're back to Greg's BWTP protocol proposal. (I
was a fan at the IETF75 BOF and still am, but for non-browser use cases.)

There might be case to say, therefore, that WebSockets message should always
be text (as the current draft does, actually) and should be automatically
parsed as JSON (which it does not). I believe that's going to far, as there
are scenarios where you DO know what content you'll be slinging about,
whether it's binary or plain text. I believe JSON will be an extremely
common case and is perfectly suited for the cases where you don't know what
data to expect, and lets us keep the WebSockets protocol simple.

Joshua