directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Panicker <vino...@gmail.com>
Subject Re: [mina] Filter design issue?
Date Sat, 30 Apr 2005 10:57:30 GMT
Hi Trustin,

Another problem with the filters now is that since they were initially
designed to work with Acceptors and Connectors, they rely on the
sessionOpened() method to start their functionality.  Since now we
would be adding the filters to already existing sessions,
sessionOpened() would never be called.  So there needs to be a new
Filter activation mechanism of some sort.

On 4/29/05, Trustin Lee <trustin@gmail.com> wrote:
> Hi Vinod,
> 
> 2005/4/30, Vinod Panicker <vinod.p@gmail.com>:
> <snip/>
> 
> > > You can downcast your ProtocolSession to IoProtocolSession and then
> > > you can get the backing IoSession so that you can add SSLFilter.  :)
> >
> > Missed that.  But IMO, since the ProtocolSession is actually using the
> > io package classes, why not have protocol as a sub-package of io?  And
> > also a proper inheritance tree that establishes this relationship.
> > All protocols are doing io anyways.
> 
> There is an in-VM pipe communication which bypasses I/O layer. ;)

IMO everything is I/O of some sort.  I'd take a re-look at the bigger
picture and refactor so that relationships between different classes
is more effectively utilized.

> > > > Suggestion would be to combine all filters into a common hierarchy and
> > > > make them applicable to Session.
> > >
> > > We can lose type safety, if we do so.  So I didn't do like that
> > > intentionally.  WDYT?
> >
> > I would still stand by having all filters applicable to sessions.  It
> > makes it much easier to use filters for different kind of sessions
> > wherever applicable.  IMO a ProtocolSession is nothing but a more
> > user-friendly version of IoSession.  Ditto with all Protocolxxx and
> > Ioxxx.
> 
> In-VM pipe support is a problem here again as you've expected.

Didn't quite get this.  Could you pls elaborate?

Regards,
Vinod.

Mime
View raw message