Re: [jetty-dev] jetty-9 websockets API

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

One more thing regarding streaming from the RFC..

IMPLEMENTATION NOTE: In the absence of any extension, a receiver
   doesn't have to buffer the whole frame in order to process it.  For
   example, if a streaming API is used, a part of a frame can be
   delivered to the application.  However, note that this assumption
   might not hold true for all future WebSocket extensions.


cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Tue, Jul 3, 2012 at 6:05 PM, Jesse McConnell
<jesse.mcconnell@xxxxxxxxx> wrote:
> inline below and chopping out sections I have no comment on having
> just gone over all this in detail with joakim
>
> --
> jesse mcconnell
> jesse.mcconnell@xxxxxxxxx
>
>>> I'm not so sure we need different classes fro
>>> Ping/Pong/Text/Data/Binary etc frames.   Specially for data, we cannot
>>> apply any interpretation on the frames themselves.  it is only when
>>> frames are aggregated into messages that we can say they are binary or
>>> text.   Also I do see scope for extensions changing both the number
>>> and type of frames as they are processed, so perhaps a single Frame
>>> class is better than polymorphic types.   If we remove the UTF-8
>>> processing from TextFrame, there is not much left of that class!
>>
>>
>> Having the individual specific frame types currently makes things easier to
>> understand, and also makes the End-User WebSocket Pojo declarations easier
>> to route/understand as well.  Should the end user want to deal with frames,
>> then  can declare which frame types they would be interested in.
>> As for going for the single Frame object approach, i would discourage that
>> as well, as it makes maintenance complicated with all of the various rules,
>> parsing, and generating that would introduce (don't want a repeat of Jetty
>> 7's monolithic generator/parser).
>> Also, when the extensions get wired back up, they will be wired up at the
>> BaseFrame level.
>> Beside, we followed the SPDY lead here too. with the individual frames.
>> And with respect to the UTF8 checks, those are just there to honor the RFC.
>
> (from RFC)
>
> The "Payload data" is text data encoded as UTF-8.  Note that a
>       particular text frame might include a partial UTF-8 sequence;
>       however, the whole message MUST contain valid UTF-8.
>
> So we don't technically have to fail fast like the AutoBahn tests
> recommend I suppose...but it is kinda nice
>
>> Now, that being said.
>> Having TextFrame's do the UTF8 check is really an inappropriate place as the
>> RFC really talks about the Message level requiring that UTF8 validation.
>>  However, the autobahn test expect validation the frames level and fail fast
>> in an example of a invalid codepoint.  The tests also allow a split
>> codepoint between frames with no failure.
>> So to resolve this we have the MessageAggregator and MessageGenerator
>> introduced below to aggregate/fragment large messages and presumably
>> validate the UTF8 requirement there.
>>
>> How about we fix the TextFrame validation for now, and re-evaluate maybe
>> going back down to 3 frame types (BaseFrame -> (DataFrame |
>> ControlFrame)) within the next few weeks (as we start integrating the
>> extension chain back into the mix).
>
> based on the grueling couple of hours we spent working through the
> streaming stuff and initial extension plans...they might just fade
> away naturally from the pain of implementation :)
>
>
>> Open Questions:
>>
>> Blocking or not? (Favoring non-blocking, but how? with an active thread?)
>> How do we interrupt / cancel the operation on an offloaded write?
>> Can any frame show up in the middle of all of the frames needed to send
>> these streams? (spec seems to indicate no)
>
> (from RFC)
>
> Control frames (see Section 5.5) MAY be injected in the middle of
>       a fragmented message.
>
> and
>
> The fragments of one message MUST NOT be interleaved between the
>       fragments of another message unless an extension has been
>       negotiated that can interpret the interleaving.
>
> and lastly
>
> An endpoint MUST be capable of handling control frames in the
>       middle of a fragmented message.
>
>
> so ControlFrames can show up, but other data frames...no, and if that
> happens an extension has to be unwinding the mess
>
> cheers,
> jesse