Re: [MINA 3] Session attributes
Why not use an enum for all the keys? On Mon, Dec 5, 2011 at 10:34 AM, Emmanuel Lécharny elecha...@apache.orgwrote: 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 AttributeKeyString(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
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écharnyelecha...@apache.orgwrote: 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 AttributeKeyString(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
[MINA 3] Session attributes
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); ... IoProcessorS processor = (IoProcessorS) session.getAttribute(PROCESSOR); ... session.setAttributeIfAbsent(PROCESSOR, processor); ... Currently, the new IoSession is using five methods to manipulate Attributes : T T getAttribute(String name); T T setAttribute(String name, T value); T T removeAttribute(String name); boolean containsAttribute(String name); SetString 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
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 Attributeshttps://issues.apache.org/jira/browse/DIRMINA-874, 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
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 Attributeshttps://issues.apache.org/jira/browse/DIRMINA-874, 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 String, Value 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_'the name, 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
What about mixing both mode ? A String, Value 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 String, Value mode.
Re: [MINA 3] Session attributes
On 12/5/11 3:52 PM, Christian Schwarz wrote: What about mixing both mode ? AString, Value 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 theString, Value 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 AttributeKeyString(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
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 AttributeKeyString(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.
