mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 이희승 "(Trustin Lee)" <trus...@gmail.com>
Subject Re: [Asyncweb] server API for commiting HTTPReponse in chunk
Date Mon, 18 Feb 2008 04:43:52 GMT
Adding commit(Partial)?Response method causes HttpResponse to keep a
response to IoSession, which doesn't sound good to me.  What do you
think about providing another setContent method with Queue<IoBuffer>?

We could provide a special implementation of Queue that allows a user to
stream a list of IoBuffers on demand.  The encoder will try to access
the queue by calling poll() to get the newest chunk.

Actually this proposal causes some changes in ProtocolCodecDecoder and
MINA itself so it can understand Queue<IoBuffer>.  However, the encoder
won't need to be changed at all.

Another trickier part is decoding.  I prefer to have HttpRequest (or
HttpResponse) to have a Queue<IoBuffer> as a content so the decoder can
offer the newly received chunk there.

On the other hand, Use of the Queue interface might be inadequate and we
might need to introduce more specialized interface like the following:

public interface IoBufferStream {
    void offer(IoBuffer buf);

    // Returns null on the end of the content.
    // Returns an empty buffer if no chunk is ready yet.
    IoBuffer poll();

    // and some listener registration...
    IoBufferStream addListener(IoBufferStreamListener listener);
    IoBufferStream removeListener(IoBufferStreamListener listener);

By having MINA core providing a standardized interface for streaming a
large list of buffer chunks will make more broad range of users happier
rather than implementing such a feature in a certain protocol provider.


2008-02-14 (목), 12:20 +0100, Julien Vermillard 쓰시길:
> Hi,
> I would like to have your comments about the Asyncweb server API
> Actually you create your HttpResponse like that : 
> MutableHttpResponse response = new DefaultHttpResponse();
> response.setContent(myIoBuffer);
> response.setHeader("Content-Type", "text/html");
> response.setStatus(HttpResponseStatus.OK);
> context.commitResponse(response);
> I like this API, it's very simple to use. I would like to keep it
> because it's *very* easy for anybody to make a simple HttpService for
> serving few data, like RPC call or anything you want.
> As Dave commented here http://jira.safehaus.org/browse/ASYNCWEB-21 it's
> totally inefficient for serving large data and streaming is impossible.
> I would like to propose a variation of Dave API idea : 
> We keep "response.setContent(myIoBuffer);" because it will fit 70% of
> the use cases :)
> We add to MutableHttpResponse a Queue of IoBuffer you can fill like you
> want for example : 
> MutableHttpResponse response = new DefaultHttpResponse();
> response.setStatus(HttpResponseStatus.OK);
> response.addContent(buffer1);
> response.addContent(buffer2);
> response.addContent(buffer3);
> response.commitResponse(response);
> So you can add content in chunks in place of 1 big buffer, that won't
> resolve the streaming problem, but it's convenient.
> Now streaming : 
> MutableHttpResponse response = new DefaultHttpResponse();
> response.setStatus(HttpResponseStatus.OK);
> // add a first chunk (optional)
> response.addContent(buffer1);
> PartialResponseListener listener = new PartialResponseListener() {
> 	public void queueEmpty(HTTPResponse response) {
> 		if(moreDataToSend) {
> 	                ...
>         	        // add more data
> 			response.addContent(buffer);
> 		} else {
> 	                // streaming is done finish the response
>         	       response.done();
> 		}
> 	}
> };
> response.commitPartialResponse(response, listener);
> What I would like to discuss here is to find a good looking API doing
> everything you can imagine about streaming (audio,commet,big
> files,etc..) before looking at impementation
> and of course with good names fitting picky Koreans :)
> Julien
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
what we call human nature is actually human habit

View raw message