Re: [WebSocket API] .binaryType

Trying to cut to the important bits, so skipped a lot.

On Sat, Sep 3, 2011 at 12:31 PM, Ian Hickson <ian@hixie.ch> wrote:
>> Regarding 1:
>> The usecase for blobs in general would be downloading large messages
>> where the contents of the message won't be immediately used, but
>> rather stored for later use. For example a offline webmail page could
>> use websocket to synchronize emails and their attachments. Here the
>> receiving page would want to receive the attachments as Blobs to be
>> stored in IndexedDB or the Filesystem API. As the WebSocket API spec
>> is currently defined, this only works if the attachments are sent in a
>> binary format. So for example HTML attachments can't be sent as text.
>>
>> I've never quite understood why only binary messages fulfills the
>> property of "being large and will only be used later".
>
> Why wouldn't you just store the attachment as text? Why would the server
> send some attachments with one frame type and others with another frame
> type? I don't really understand why the server wouldn't just use binary
> for everything here, especially since the client side is going to treat
> them all the same anyway.

Yes, this is what it comes down to. I don't have a particularly good
answer here. It does however seem strange to me that we're assigning
semantic meaning to binary vs. text. I.e. we're saying that if you
want to send large data chunks that the client might not need to
immediately process, you should send it as binary frames.

I'm sure that in cases where the client and the server is operated by
the same entity, this won't be a problem, simply change the server to
the client's needs.

For cases where that is not the case, clients will simply have to work
around this limitation in the API by using more memory. I don't really
have a sense for how often this could be the case.

>> 2. Allow .binaryType/.dataAsBlob only during message and open events.
>> This would allow the implementation to for example hold incoming data
>> in memory until after the previous message event has been fully
>> dispatched. This way no unneccesary IO is done. Under normal
>> circumstances (where the bandwidth to the server is proportional to
>> todays bandwidths, and where developers try to maintain a responsive
>> UI) this implementation strategy will work quite well. More complex
>> implementation strategies can of course still be used, but in either
>> case the implementation doesn't have to worry about the format
>> changing once the previous event has been dispatched.
>
> I'm happy to limit binaryType to only being changed when a message is
> received, but in some simple situations that seems like it would make the
> API needlessly complex. Consider a server that just never sends anything
> unsolicited, paired with a client that never has two pending requests at a
> time -- it always waits for the previous reply before asking for something
> else. This would not be a sophisticated app, but it nevertheless is likely
> to describe many typical deployments. In such cases, the client knows what
> it wants to do with the next frame as soon as it asks the server for it,
> and it will not receive a frame between sending the request and receiving
> the frame for which it wants the data in a particular format. The author
> could have the server send a blank text frame just before the binary frame
> just so that the client could set binaryType accordingly, but that would
> obviously just be the author working around an API limitation.

Good point. I do think we should support this use case, and it does
indeed require being able to set .binaryType at any point.

Given that no-one else has replied, we'll simply go forward with the
current API.

/ Jonas

Received on Saturday, 10 September 2011 01:14:43 UTC