Initial comments on coyote

[cm...@yahoo.com]

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 ).

- 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 )

- 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 ). 

Costin

Re: Initial comments on coyote

[Remy Maucherat <re...@apache.org>]

> 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