You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by peter royal <pr...@apache.org> on 2006/09/20 07:04:38 UTC
ExpiringMap and IoServiceConfig.getSessionRecycler
Why is this in IoServiceConfig? Its not applicable to all transports.
I propose we make a DatagramServiceConfig interface, common to the
two Datagram configs, and move the method there. There will be slight
code duplication (the set/get and defaults), but I think that's
better than polluting the core interfaces.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: ExpiringMap and IoServiceConfig.getSessionRecycler
Posted by peter royal <pr...@apache.org>.
On Sep 20, 2006, at 12:58 AM, Trustin Lee wrote:
> I did it by myself. Now you won't see a sessionRecycler property from
> IoServiceConfig.
awesome, thanks!
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: ExpiringMap and IoServiceConfig.getSessionRecycler
Posted by Trustin Lee <tr...@gmail.com>.
Hi Peter,
On 9/20/06, Trustin Lee <tr...@gmail.com> wrote:
>
> On 9/20/06, peter royal <pr...@apache.org> wrote:
> >
> > On Sep 19, 2006, at 10:16 PM, Trustin Lee wrote:
> > > Greg and I actually considered creating an interface that abstracts
> > > DatagramAcceptor/ConnectorConfig, say
> > > ConnectionlessIoServiceConfig. The
> > > name was extraordinarilly long, so we just put that property to
> > > IoServiceConfig and documented that the property will only affect
> > > connectionless transports. You are right that it is placed in a
> > > long place,
> > > but putting it into DatagramServiceConfig is also not really a good
> > > option.
> > > Should we just use ConnectionlessIoServiceConfig, or other better
> > > name?
> >
> > What's wrong with putting it in a DatagramServiceConfig, seeing as
> > its datagram-only at the moment?
>
>
> Hmm, I see. Then let's create DatagramServiceConfig and put it there, and
> create the super interface when more transports comes into play.
>
I did it by myself. Now you won't see a sessionRecycler property from
IoServiceConfig.
Thanks for the wise advice,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: ExpiringMap and IoServiceConfig.getSessionRecycler
Posted by Trustin Lee <tr...@gmail.com>.
On 9/20/06, peter royal <pr...@apache.org> wrote:
>
> On Sep 19, 2006, at 10:16 PM, Trustin Lee wrote:
> > Greg and I actually considered creating an interface that abstracts
> > DatagramAcceptor/ConnectorConfig, say
> > ConnectionlessIoServiceConfig. The
> > name was extraordinarilly long, so we just put that property to
> > IoServiceConfig and documented that the property will only affect
> > connectionless transports. You are right that it is placed in a
> > long place,
> > but putting it into DatagramServiceConfig is also not really a good
> > option.
> > Should we just use ConnectionlessIoServiceConfig, or other better
> > name?
>
> What's wrong with putting it in a DatagramServiceConfig, seeing as
> its datagram-only at the moment?
Hmm, I see. Then let's create DatagramServiceConfig and put it there, and
create the super interface when more transports comes into play.
Does anyone have a secret transport that's not UDP and also
> connectionless? We can always refactor later to make an interface to
> represent such transports.
True.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: ExpiringMap and IoServiceConfig.getSessionRecycler
Posted by peter royal <pr...@apache.org>.
On Sep 19, 2006, at 10:16 PM, Trustin Lee wrote:
> Greg and I actually considered creating an interface that abstracts
> DatagramAcceptor/ConnectorConfig, say
> ConnectionlessIoServiceConfig. The
> name was extraordinarilly long, so we just put that property to
> IoServiceConfig and documented that the property will only affect
> connectionless transports. You are right that it is placed in a
> long place,
> but putting it into DatagramServiceConfig is also not really a good
> option.
> Should we just use ConnectionlessIoServiceConfig, or other better
> name?
What's wrong with putting it in a DatagramServiceConfig, seeing as
its datagram-only at the moment?
Does anyone have a secret transport that's not UDP and also
connectionless? We can always refactor later to make an interface to
represent such transports.
Otherwise, how about StatelessIoServiceConfig?
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: ExpiringMap and IoServiceConfig.getSessionRecycler
Posted by Trustin Lee <tr...@gmail.com>.
On 9/20/06, peter royal <pr...@apache.org> wrote:
>
> Why is this in IoServiceConfig? Its not applicable to all transports.
>
> I propose we make a DatagramServiceConfig interface, common to the
> two Datagram configs, and move the method there. There will be slight
> code duplication (the set/get and defaults), but I think that's
> better than polluting the core interfaces.
Greg and I actually considered creating an interface that abstracts
DatagramAcceptor/ConnectorConfig, say ConnectionlessIoServiceConfig. The
name was extraordinarilly long, so we just put that property to
IoServiceConfig and documented that the property will only affect
connectionless transports. You are right that it is placed in a long place,
but putting it into DatagramServiceConfig is also not really a good option.
Should we just use ConnectionlessIoServiceConfig, or other better name?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6