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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

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