Hello Charlie,
> ------- Additional comments from huntch_at_dev.java.net Tue Aug 14 14:51:54 +0000 2007 -------
> The potential problem with modifying or removing an existing interface is that
> we may break existing applications that may be using it. Hence, I do not think
> we can remove SelectionKeyHandler.expire(SelectionKey, long) from the
> SelectionKeyHandler interface.
>
Agree, however once we will be able to remove this method from interface
(for example for Grizzly 1.6) - think it makes sense to do it.
> The fundamental issue here is that we do not have the flexibility to configure a
> Grizzly transport in a manner that does not do "expiring of keys". This
> includes (and not necessarily an exhaustive list):
> 1.) Controller.doSelect() should only do "expiring of keys" for those
> applications that need it, (which should be the default). Applications that do
> not need "expiring of keys" should be able to disable this functionality.
>
Right now it's possible by extending DefaultSelectionKeyHandler's
expire(Set<SelectionKey>) method. May be we can rename it, because now
possible "expire" sounds to strong... but something like
"postProcessKeys" or similar.
DefaultSelectionKeyHandler will work with "expiring of keys" enabled,
but developer could provide his own SelectionKeyHandler, which will
disable it.
> 2.) The attaching of a Long (System.currentTimeMillis()) to a SelectionKey's
> attachment should not be mandatory. Again, this should be the default since
> "expiring keys" is the default configuration. But, when it is not desired, then
> any attaching of a Long (System.currentTimeMillis()) should not be done at
> "accept time", or in any other location.
>
Right now think we have a mess with attachments: Long, Attachment ...
etc. We have to come to some consistent/extensible attachment type,
which will be universal for all/most usecases. May be it could be some
Map, which can be attached to SelectionKey and will be able to hold
custom attachments? Because right now in one place we expect Long, on
other Attachment, and if developer will need his own type...
> In other words, we need to be able to have the default configuration for a
> Grizzly transport that enables "expiring keys" *and* we need to be able to
> configure a Grizzly transport that disables the "expiring keys" features and any
> of its artifacts.
>
Agree.
WBR,
Alexey.
> Perhaps this is justification for integrating a TransportConfiguration interface
> / object that allows one to configure a Grizzly transport more easily.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: issues-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: issues-help_at_grizzly.dev.java.net
>
>