Ok, ok. I'll work around it. Costin
On Tue, 9 Apr 2002, Remy Maucherat wrote: > > On Mon, 8 Apr 2002, Remy Maucherat wrote: > > > > > > > > I'd like those two to stay the way they are. They're not related to the > > > hooks or actions. I/O should be handled as a special case IMO; faster + > > > simpler. (could you remove the comments ?) > > > > Ok, but at least add a second parameter ( Request, Response, etc ) to > > allow stateless implementation. > > Why ? The lifecycle is tied to the request/response lifecycle anyway. It > doesn't make any sense. > > > Implementing input/output as a regular callback from coyote to the > > protocol impl. is IMO cleaner and is not much slower. I'm fine with > > them as special case if you want it this way. > > I don't see the point, except if you thinks casts are cleaner (and having a > giant if/else in the main processing loop). > > > But can we at least add the extra param ? > > There's no point. > I would need the setReq/setResp methods on the filters anyway, as this is > when you're supposed to read the headers the filter need. > > Remy > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
