On 7 October 2011 21:08, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> Although you say this should be abstracted away, I would
> still prefer an API with full knowledge of frames.
Really? that is equivalent to saying you want servlets to have full
knowledge of HTTP chunks.
Frames are completely ephemeral and may not even survive a pass
through the local implementation, let alone any intermediaries or the
WS implementation at the other end point. They convey no meaning at
all for the application.
> If the frames can really be edited at will by the container, then it is
> technically possible to use a buffer API only, but this could still be
> less efficient for certain apps maybe ?
I agree entirely. There is definitely a class of application where a
message based API will be less efficient (or worse if memory
constraints are hit). Streaming is one way to deal with such
application, but so is prohibition by limits (which browsers already
do for WS and servers already do for headers, URLs, forms).
The choice of prohibition vs streaming is entirely dependent on how
frequent such large message cases will be.
Either we think they are definitely going to be frequent, in which
case we should support streaming in the next revision.
Or we think they are going to be rare, in which case we don't need to
add streaming in this release, but can wait to see if there is demand
and add is a subsequent revision if need be.
> The output will need some listener callback to control blocking (the
> application could write an arbitrary amount of buffers very quickly
> otherwise, with no way to know if they have be sent already), so
> ultimately this is quite similar.
True. SendMessage(ByteBuffer) and
message.getOutputStream().write(ByteBuffer) have essentially identical
semantics when it comes to blocking and/or the need for asynchronous
callbacks. Writing is somewhat unrelated to message size, as previous
messages may have already filled localbuffers and the communication
channel - although the stream based API does have the concern of
partially sent messages in the asynchronous case.
So for both APIs styles we need to decide if a blocking API is
sufficient, or do we need asynchronous support to deal with unsent
messages.
Jetty currently offers only a blocking send for WS (which mostly does
not block as it copies to a buffer which is asynchronously flushed,
and blocks only if the buffer is full). In the limited exposure this
has had, it has not been an issue for applications or scalability.
But this is early days.
I do think that a simple blocking message based API is going to cover
the vast majority of use cases and thus I think it should be a first
goal to achieve in the API. Then we can consider streams and/or
asynchronous WS either later in this spec cycle or in the next, as
more evidence of need is collected.
cheers