hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: NHttpXXHandler Impl Improvements?
Date Wed, 13 Feb 2008 20:50:19 GMT
Sam Berlin wrote:
> After looking through things, there seems to already be somewhat of an
> infrastructure for NIO entities using the
> o.a.http.nio.entity.HttpNIOEntity and its subclasses.  Those entities
> appear to expose a 'getChannel' method (used right now just in the
> NHttpFileServer example).  I propose a change in that interface, to
> make it a little more analagous to the HttpEntity interface.
> Currently HttpEntity has a blocking 'writeTo' method and a
> 'getContent' method returning the InputStream.  HttpNIOEntity just has
> the 'getChannel' method, but no non-blocking 'produceContent' method.
> 
> Is it OK right now to completely change interfaces/classes in
> http-nio? 

Not unless we absolutely have to. Preferably we should initially 
deprecate those interfaces we intent to delete in the future.


  If so, I would like to make HttpNIOEntity into a copy of
> the HttpNIOEntity we're using internally.  That is:
> 

I kind of dislike that this interface has both produceContent and 
consumeContent methods. Would it be ok if we split things into two 
distinct interfaces?


How about this?

interface ContentProducingHttpNIOEntity extends HttpNIOEntity {

      void produceContent(ContentEncoder encoder, IOControl ioctrl)
              throws IOException;

      void finish();

}


interface ContentConsumingHttpNIOEntity extends HttpNIOEntity {

      int consumeContent(ContentDecoder decoder, IOControl ioctrl)
             throws IOException;

      void finish();

}

Better names are very welcome.

Oleg

> /**
>  * Defines an interface for event based HTTP entities.
>  */
> public interface HttpNIOEntity extends HttpEntity {
> 
>     /**
>      * Reads data from <code>decoder</code>.
>      *
>      * @param decoder the decoder for reading input
>      * @param ioctrl I/O control for suspending and resuming events
>      * @return the number of bytes read
>      * @throws IOException indicates an I/O error which will abort the
>      *         connection
>      */
>     int consumeContent(ContentDecoder decoder, IOControl ioctrl)
>             throws IOException;
> 
>     /**
>      * Writes data to <code>encoder</code>.
>      *
>      * @param encoder the encoder for writing output
>      * @param ioctrl I/O control for suspending and resuming events
>      * @throws IOException indicates an I/O error which will abort the
>      *         connection
>      */
>     void produceContent(ContentEncoder encoder, IOControl ioctrl)
>             throws IOException;
> 
>     /**
>      * Invoked when processing has completed. This completes the transfer of the
>      * entity and is invoked when processing finishes normally, i.e.
>      * {@link ContentEncoder#isCompleted()} or
>      * {@link ContentDecoder#isCompleted()} return true, or when an exception
>      * occurs.
>      */
>     void finished();
> 
> }
> 
> This moves the burden of reading/writing non-blocking content to the
> entity itself (much like it already does for writing, using writeTo).
> Retrieving the channel is removed because it becomes unnecessary (and
> could be cumbersome for some entities).  The 'finished' method is to
> signal that the entity can reclaim resources, and would be called when
> the connection closes or the entity has completed its writing|reading
> (according to the encoder|decoder).
> 
> Given that all entities are created within the Service|ClientHandlers
> or within NHttpConnectionBase, it should be pretty easy to require
> that all entities used in an NIO context implement this new
> HttpNIOEntity.  And the fact that the interface & some implementations
> already exist makes things a little easier, because the planning
> already is done.  It's just the use of the classes (and when they're
> used) that needs to change.
> 
> Any thoughts on the approach?  I haven't fully examined the 'client'
> side of it yet -- am mostly approaching it on the server-side right
> now, so there could be hitches there.
> 
> Sam
> 
> On 2/12/08, Sam Berlin <sberlin@gmail.com> wrote:
>>> Pretty much 100% if this code comes with a reasonable test coverage.
>>> Moreover, the contributor of this code will qualify for a full
>>> committership on the project for such such a substantial contribution,
>>> in my opinion.
>> Cool, Ok.  I'll see how it goes (and if the buffered scheme can be deprecated).
>>
>> Sam
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message