Re: [MINA3] Some points
Le 4/8/13 5:46 PM, Jeff MAURY a écrit :
> Hello,
>
> as I has been working on the Codec API and MINA3, I have some points I want
> to share with you:
>
> 1) Codec API
> The new Codec API does not define exceptions. It seems that the old one
> does with the notion of recoverable exception, should we define exceptions
> as well or no. If no, then we should document how an exception should be
> generated (RuntimeException, any other) and which are the preferred ones.
We already discussed aout the exceptions, and how they should be
handled, and up to a point, we decided to not create an exceptionCaught
event - like what we have in Mina2 -, but this was not a final decision.
All in all, this is an aspect which is not well covered yet.
> Also, the decoder is expected to return an array of object, wouldn't it
> better to return a Collection ?
Depends. I don't even know if it's a good idea at all to return a list
or an array of decoded objects. What about sending each decoded message
as soon as we have one, keeping the current state for further calls ?
The idea would be to have a non-blocking decoder we can use this way :
while ( ( message = decode( data ) ) != null ) {
do somethng with the decoded message
}
?
>
> 2) Session objects are not immutable
> I noticed that session objects (assigned to clients and servers) are not
> immutable, but I think changing properties of such objects may lead to
> unexpected behavior. Would the Builder pattern more accurate ?
Not sure. The session might change, as we store attributes into it.Jeff
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] Some points
On Mon, Apr 8, 2013 at 6:04 PM, Emmanuel Lécharny wrote:
> Le 4/8/13 5:46 PM, Jeff MAURY a écrit :
> > Hello,
> >
> > as I has been working on the Codec API and MINA3, I have some points I
> want
> > to share with you:
> >
> > 1) Codec API
> > The new Codec API does not define exceptions. It seems that the old one
> > does with the notion of recoverable exception, should we define
> exceptions
> > as well or no. If no, then we should document how an exception should be
> > generated (RuntimeException, any other) and which are the preferred ones.
> We already discussed aout the exceptions, and how they should be
> handled, and up to a point, we decided to not create an exceptionCaught
> event - like what we have in Mina2 -, but this was not a final decision.
>
> All in all, this is an aspect which is not well covered yet.
>
> > Also, the decoder is expected to return an array of object, wouldn't it
> > better to return a Collection ?
> Depends. I don't even know if it's a good idea at all to return a list
> or an array of decoded objects. What about sending each decoded message
> as soon as we have one, keeping the current state for further calls ?
> The idea would be to have a non-blocking decoder we can use this way :
>
> while ( ( message = decode( data ) ) != null ) {
> do somethng with the decoded message
> }
>
> ?
>
I think it will be better in terms of error reporting because we have an
all or nothing interface now.
>
> >
> > 2) Session objects are not immutable
> > I noticed that session objects (assigned to clients and servers) are not
> > immutable, but I think changing properties of such objects may lead to
> > unexpected behavior. Would the Builder pattern more accurate ?
>
> Not sure. The session might change, as we store attributes into it.Jeff
>
Sorry I was talking about config objets, not session ones.
Jeff
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Jeff MAURY
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Re: [MINA3] Some points
Le 4/8/13 6:20 PM, Jeff MAURY a écrit : > On Mon, Apr 8, 2013 at 6:04 PM, Emmanuel Lécharny wrote: > >> Le 4/8/13 5:46 PM, Jeff MAURY a écrit : >> >>> 2) Session objects are not immutable >>> I noticed that session objects (assigned to clients and servers) are not >>> immutable, but I think changing properties of such objects may lead to >>> unexpected behavior. Would the Builder pattern more accurate ? >> Not sure. The session might change, as we store attributes into it.Jeff >> > Sorry I was talking about config objets, not session ones. AFAICT, there are few config objects that can change. But for instance, the chain may change dynamically (for instance, we may want to activate or desactivate the logger filter). Do you have any other config object in mind ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA3] Some points
Hi Happy to see some feedback :) On Mon, Apr 8, 2013 at 5:46 PM, Jeff MAURY wrote: > Hello, > > as I has been working on the Codec API and MINA3, I have some points I want > to share with you: > > 1) Codec API > The new Codec API does not define exceptions. It seems that the old one > does with the notion of recoverable exception, should we define exceptions > as well or no. If no, then we should document how an exception should be > generated (RuntimeException, any other) and which are the preferred ones. > Also, the decoder is expected to return an array of object, wouldn't it > better to return a Collection ? > I'm agreeing here for just returning one object and we loop. It will be much simpler. And no need to create an array/collection when you decoded only 1 object. 2) Session objects are not immutable > I noticed that session objects (assigned to clients and servers) are not > immutable, but I think changing properties of such objects may lead to > unexpected behavior. Would the Builder pattern more accurate ? > > Some are mutable (the one used as default in the IoService) and some are just proxy on the underlying java.net.Socket methods. I'm not a big fan of builders and "fluent" APIs but I'm curious to see alternative proposal for those configuration classes :) Julien
