Ok, I'm going to tentatively use:
NHttpEntity extends HttpEntity { void finish(); }
ContentConsumingNHttpEntity extends NHttpEntity { consumeContent(..); }
ContentProducingNHttpEntity extends NHttpEntity { produceContent(..); }
The names are a bit iffy, but can't think of anything better at the
moment. Separating the interfaces is a good idea -- should make the
end result a lot cleaner.
Sam
On 2/13/08, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> 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.
> > * [EMAIL PROTECTED] ContentEncoder#isCompleted()} or
> > * [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
