First off, sorry for the LATE response tot his thread. My comments are
below inline.
이희승 (Trustin Lee) wrote:
> 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.
>
> WDYT?
Don't we already have the equivalent of an IoBufferStream with just
IoSession.write() and IoHandler.messageReceived()? It seams like this
would add a lot of complication just to solve the problem of partial
HTTP responses from AsyncWeb server. Also, wouldn't use a Queue require
the decode to block waiting for messages to send?
That being said, I don't like the HttpResponse object holding the
IoSession either. You also have to think about the HTTP client. On the
client side it doesn't make any sense to have an addContent on an HTTP
response.
I'm more inclined toward something like:
public interface PartialResponse {
void write(Object message);
void done();
addListener(PartialWriteListener listener);
removeListener(PartialWriteListener listener);
}
public interface PartialWriteListener {
void onWriteCompletion(PartialResponse partialResponse, Object
writtenMessage);
}
You would then do something like:
PartialResponse partial = response.commitPartialResponse(httpResponse);
partial.write(startofData);
partial.addListener(new PartialWriteListener() {
void onWriteCompletiion(PartialResponse partialResponse, Object
writtenMessage) {
if (noMoreData) {
partialResponse.done();
} else {
partialResponse.write(moreData);
}
}
});
Thoughts?
Of course, we still have to incorporate exception handling if an
exception is thrown from the listener as Tuure pointed out and this
doesn't address the notion of setting a chunk size as David pointed out.
-Mike
>
> 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
