[MINA 3] Session attributes

[Emmanuel Lecharny]

Hi,

in MINA 2, session's attributes were stored using the AttributeKey 
class, which was concatenating a class name and a name :


private static final AttributeKey PROCESSOR = new AttributeKey( 
SimpleIoProcessorPool.class, "processor");

...
IoProcessor processor = (IoProcessor) 
session.getAttribute(PROCESSOR);

...
session.setAttributeIfAbsent(PROCESSOR, processor);
...

Currently, the new IoSession is using five methods to manipulate 
Attributes :

 T getAttribute(String name);
 T setAttribute(String name, T value);
 T removeAttribute(String name);
boolean containsAttribute(String name);
Set getAttributeNames();

All of them take a String as a key (the name), and a generic value.

I would suggest that we don't use the AttributeKey class at all, and 
instead, define each internal MINA Attribute by prefixing them with 
'__'. For instance, the SslContext would use the '__SslContext' key. The 
rational is that there is no reaon to use complex key, even if we have 
some collision risks.


wdyt ?



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] Session attributes

[Christian Schwarz]

Hi,


I would suggest that we don't use the AttributeKey class at all, and
> instead, define each internal MINA Attribute by prefixing them with '__'.
> For instance, the SslContext would use the '__SslContext' key. The rational
> is that there is no reaon to use complex key, even if we have some
> collision risks.
>

As mentiont in ticket [DIRMINA-874] Typesafe
Attributes,
i think a AttributeKey is a good tool to provide typesafey and a reduced
risk of key-collisions. The most time i get confused with String
attribute-keys in MINA 2, is when some one uses a String for more than one
purpose (e.g. attribute-key & nls-key ). If we have one key-type we can
prevent users to abuse a attribute-key for an other purpose.

The idea of an '__' prefix is still possible, but i think a prefix like
'internal' is more expressive for those how don't read deep in the API-Docs.

Chris

Re: [MINA 3] Session attributes

[Emmanuel Lécharny]

On 12/5/11 3:32 PM, Christian Schwarz wrote:

Hi,


I would suggest that we don't use the AttributeKey class at all, and

instead, define each internal MINA Attribute by prefixing them with '__'.
For instance, the SslContext would use the '__SslContext' key. The rational
is that there is no reaon to use complex key, even if we have some
collision risks.


As mentiont in ticket [DIRMINA-874] Typesafe
Attributes,
i think a AttributeKey is a good tool to provide typesafey and a reduced
risk of key-collisions. The most time i get confused with String
attribute-keys in MINA 2, is when some one uses a String for more than one
purpose (e.g. attribute-key&  nls-key ). If we have one key-type we can
prevent users to abuse a attribute-key for an other purpose.

Yes, I read your JIRA (and replied).

What about mixing both mode ? A  mode for simple usage, 
and a typesafe mode, as you suggested (that means we will have two 
different kind of map to store both elements).





The idea of an '__' prefix is still possible, but i think a prefix like
'internal' is more expressive for those how don't read deep in the API-Docs.
It can be 'internal_', sure. Doesn't matter too much here, 
it's just about avoiding collision as much as we can.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] Session attributes

[Christian Schwarz]

>
> What about mixing both mode ? A  mode for simple usage, and
> a typesafe mode, as you suggested (that means we will have two different
> kind of map to store both elements).


I think two modes is one mode to much, it would confuse the user and the
typesafe aspect would be underminded by the  mode.

Re: [MINA 3] Session attributes

[Emmanuel Lécharny]

On 12/5/11 3:52 PM, Christian Schwarz wrote:

What about mixing both mode ? A  mode for simple usage, and
a typesafe mode, as you suggested (that means we will have two different
kind of map to store both elements).


I think two modes is one mode to much, it would confuse the user and the
typesafe aspect would be underminded by the  mode.


As a user, having to create a new instance to hold the key and value 
might be seen as heavy, don't you think ?


session.set(new AttributeKey(String.class,"myKey"),"myAttribute");

is a bit more complex than

session.set( "myKey", "myAttribute" );

Or is it just me ?

(don't get me wrong, I understand the rational behind your proposal, 
it's far superior than what I currently propose, but I'm not sure the 
extra complexity worth it... Just my personal opinion, here).


thoughts ?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] Session attributes

[Christian Schwarz]

As a user, having to create a new instance to hold the key and value might
> be seen as heavy, don't you think ?
>
> session.set(new AttributeKey(String.**
> class,"myKey"),"myAttribute");
>
> is a bit more complex than
>
> session.set( "myKey", "myAttribute" );
>
> Or is it just me ?
>

It's true for your example! I don't know, but i think the most developers
would use a 'final static'- constant for there keys, to avoid misspelling
and to reduce the memory footprint. I my huble opinion the heavier
constuction process (+ ~5sec) could save time because i don't have to test
and/or debug, if set an attribute of the wrong  type accidently. I think we
need more opinions here, to see what the future users might think about the
pro & contra.

Re: [MINA 3] Session attributes

[Emmanuel Lécharny]

On 12/5/11 4:32 PM, Christian Schwarz wrote:

As a user, having to create a new instance to hold the key and value might

be seen as heavy, don't you think ?

session.set(new AttributeKey(String.**
class,"myKey"),"myAttribute");

is a bit more complex than

session.set( "myKey", "myAttribute" );

Or is it just me ?


It's true for your example! I don't know, but i think the most developers
would use a 'final static'- constant for there keys, to avoid misspelling
and to reduce the memory footprint. I my huble opinion the heavier
constuction process (+ ~5sec) could save time because i don't have to test
and/or debug, if set an attribute of the wrong  type accidently. I think we
need more opinions here, to see what the future users might think about the
pro&  contra.
Totally agree. And we can still change in a near future, before freezing 
the code.


Note that your proposal is closer to MINA 2, so a migration would be 
easier (another pro for your proposal).



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] Session attributes

[Chad Beaulac]

Why not use an enum for all the keys?


On Mon, Dec 5, 2011 at 10:34 AM, Emmanuel Lécharny wrote:

> On 12/5/11 4:32 PM, Christian Schwarz wrote:
>
>> As a user, having to create a new instance to hold the key and value might
>>
>>> be seen as heavy, don't you think ?
>>>
>>> session.set(new AttributeKey(String.**
>>> class,"myKey"),"myAttribute");
>>>
>>> is a bit more complex than
>>>
>>> session.set( "myKey", "myAttribute" );
>>>
>>> Or is it just me ?
>>>
>>>  It's true for your example! I don't know, but i think the most
>> developers
>> would use a 'final static'- constant for there keys, to avoid misspelling
>> and to reduce the memory footprint. I my huble opinion the heavier
>> constuction process (+ ~5sec) could save time because i don't have to test
>> and/or debug, if set an attribute of the wrong  type accidently. I think
>> we
>> need more opinions here, to see what the future users might think about
>> the
>> pro&  contra.
>>
> Totally agree. And we can still change in a near future, before freezing
> the code.
>
> Note that your proposal is closer to MINA 2, so a migration would be
> easier (another pro for your proposal).
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>

Re: [MINA 3] Session attributes

[Emmanuel Lécharny]

On 12/7/11 2:58 PM, Chad Beaulac wrote:

Why not use an enum for all the keys?


There is no such thing like a generic Enum type which would be inherited 
by all Enums.


Something like session.addAttribute( Enum, Object ) is not possible.

Of course, if we define the addAttribute method as :

addAttribute(Object, Object)

that would be possible.





On Mon, Dec 5, 2011 at 10:34 AM, Emmanuel Lécharnywrote:


On 12/5/11 4:32 PM, Christian Schwarz wrote:


As a user, having to create a new instance to hold the key and value might


be seen as heavy, don't you think ?

session.set(new AttributeKey(String.**
class,"myKey"),"myAttribute");

is a bit more complex than

session.set( "myKey", "myAttribute" );

Or is it just me ?

  It's true for your example! I don't know, but i think the most

developers
would use a 'final static'- constant for there keys, to avoid misspelling
and to reduce the memory footprint. I my huble opinion the heavier
constuction process (+ ~5sec) could save time because i don't have to test
and/or debug, if set an attribute of the wrong  type accidently. I think
we
need more opinions here, to see what the future users might think about
the
pro&   contra.


Totally agree. And we can still change in a near future, before freezing
the code.

Note that your proposal is closer to MINA 2, so a migration would be
easier (another pro for your proposal).



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com





--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com