Re: [hybi] frame length encoding

[gustav <[e-mail]>]

On 22 August 2010 11:34, Shelby Moore <[e-mail]> wrote:

> Hi Brian,
>
> I think you reply is really important and I need to make it clear to the
> list that I am not trying to cause bad feelings.  My sincere apologies.
>
> >> 64-bit computing is rogue? I thought it was a desired advancement.
> >>
> >>
> > I never said "64-bit is rogue."  You frequently use hyperbole on this
> list
> > and reframe other peoples' comments in order to try to put more weight
> > behind your arguments and subtly vilify your debate opponent.
>
> I apologize.  I will try to be more conscious of the considerate tone in
> the way I word my feedback. I was just being frank as to what is my
> reaction. I am historically accustomed to working in small groups that
> speaking frankly about design considerations. A common joke of my former
> boss when I was much younger, was "NFG" (no f-ing good). Given he could
> memorize a whole page of a phone book by looking at it for a few seconds,
> I guess I learned to respect his method (shocked me when I was first
> indoctrinated into the culture).
>
> below...
>
> >  That said,
> > I'm going to take a minimal approach in my response:
> >
> > Regarding all your 64-bit comments.. the frame size has absolutely
> nothing
> > to do with "64-bit computing."  A discussion for "64-bit computing"
> should
> > have no bearing whatsoever on this protocol's length field in the header.
>
> But you argued that Javascripts inability to do 64-bit computing was a
> justification for not doing a 64-bit frame size. So I thought you started
> that discussion. Apologies for that.
>
>
> >  The only thing that truly matters are what kinds of messages we want to
> > handle with the protocol.  My point is that there's no reason for a
> > websocket client or server to handle a single message >4GB.
>
>
> You won't have to.  You will tell the other end your maximum frame size on
> the connection handshake, then the other end will re-fragment if
> necessary.
>
>
> >  For my chat
> > server that I'm building, any incoming message larger than 64KB is likely
> > to
> > be ill-intended, and that's a very generous threshold.  Clearly the
> > threshold would be different for someone else's application.
>
> Apologies I forgot to make the above point in my prior reply. I could have
> been more concensus driven with that.
>
> >> And if you do one day accept the need to move to 64-bit computing, how
> >> difficult will it be to come back and redo WS and get the new version
> >> adopted in reasonable time?
> >>
> >> I say the push to 64-bit is now and we are derelict in our duties if
> >> release a new protocol that is looking backwards about 2 decades.  I
> >> relented on my 128-bit suggestion.
> >>
> >
> > More hyperbole.  See above.  128-bit is way beyond absurd for a WebSocket
> > message length, whether today, tomorrow, or ever.
>
> I said I relented on the 128-bit.  I wasn't still arguing for it.  I had
> presented it in order to be complete in our design analysis, so that
> anyone in future wants to know why we did not support 128-bit, then they
> will see our logic written down.
>
> I do agree that I should not have made the point that you need to process
> 64-bit frames.  That would not be a free market. Rather we must have
> re-fragmentation, so that no WS server has to be forced into any maximum
> size.
>
>
> > <snip>
> >
> > I deduce/conjecture that WS will also be used to replace Flash in HTML5,
> >
> >> so that users can get video streaming without a plugin or Flash server
> >> license. And I think we also need to consider the amateur webserver
> >> programmers who simply want to dump a sendFile() of their DVD to client
> >> who can display it.  We don't want to limit the simple optimization (DMA
> >> -> NIC, no CPU load) that capability to sysadmins who understand
> >> low-level
> >> TCP tricks.  It doesn't cost you anything on the intermediary or client
> >> side, as we have to support re-fragmentation (and/or negotiation on
> >> handshake) any way (because no matter what maximum size we choose, not
> >> all
> >> intermediaries will necessarily support it).
> >>
> >>
> > It may well be helpful in replacing flash for things like games, but not
> > video.
> >
> > There are already competing methodologies for streaming HTML5 video and
> > even
> > advanced functionality like dynamic ad insertion.  For just one example
> > see
> > http://www.mdialog.com/
> >
> > A standardized way to do HTML5 Video streaming is something that should
> be
> > undertaken by another working group in relation to the <video> tag.  So
> > yes,
> > I feel rather strongly that video streaming would be an abuse of
> > WebSockets.
>
>
> Thank you for clarifying that.
>
> So then why are people mentioning a DVD in conjunction with sendFile()
> issue?  Is that all hyperbole too?
>
> And why couldn't video be streamed on top of WS? There can be any protocol
> on top of WS that can do extra features such as ads.  How do we know the
> standardized way won't end up being on top of WS?
>
>
> >> > This
> >> > is not and should not be an all-things to all-people protocol.
> >>
> >> Why not?
> >>
> >
> > Because it wasn't originally intended to be.  It solves a specific
> problem
> > rather well -- the ability of JavaScript-based applications in the
> browser
> > to participate in bi-directional communications with a server.  That's
> > what
> > it was meant for.  Opening up the scope of the protocol is a distraction
> > from getting it optimally correct for its originally intended purpose.
>
>
> What is sub-optimal about the Option 2 with 63-bit capability with respect
> to Javascript?
>
> Nothing.
What do we know about the future java script capabilities ?.
There is no reason to ask for limitations based on the current inabilities
of java script,
neither regarding performance or function, those metrics are indeed evolving
extremely fast.
Jscript clients can like any other use what they currently can, the rest is
optional and gives room to grow into.

regards
  gustav trede