> Hi Remy,
>
> I looked at coyote, and it looks good ( the Request and Response are
> simplified and have no deps on a higher layer ).
>
> Few issues:
> - Note - the user should be able to store any object as a note, there is
> no reason to require "recycle" on it ( if you want you could turn it into
> "Recyclable" and check objects in the note[] for this interface ).
I guess it's also easy for the "client" adapter to handle the recycling by
itself if it wants to. I think I'll move back to storing objects there.
> - AdapterListener/AdapterEventCode - that's an excelent idea ( to use the
> "standard" Event/Listener model on connectors). But I think you should
> follow the full pattern ( method signature doesn't match, Event must
> extend j.u.Event ). I'm also not sure what's your intention for the even
> direction ( is it intended to notify the layer above about the connector
> events or to notify the connector about server events - I think both are
> needed )
That's up in the air. I'd like to see what I need when I try to "port" (it
won't be a port since I'll rewrite parts of it to support additional things,
like pluggable content encoding support + more performance) the HTTP
connector. I didn't use the standard Java pattern mostly because I didn't
like it.
> - Connector/Adapter interfaces - I'm not sure we need them from now, but
> if you want to follow the event/listener model it would be nice to use it
> here to.
>
> I really like the idea of using only the simple Event/Listener pattern, I
> think it would be very easy for developers to understand the code and
> would allow maximum flexibility and decoupling.
>
> Would you mind moving the Request/Response in o.a.t.util.http ? They
> depend on MimeHeader, etc - and it would make sense to call them
> HttpRequest or JTCRequest or something like that ( Request is used in 3.3,
> 4.0 - it would be confusing ).
Perhaps. (Hey, there's no code left if I do that ;-))
Remy
