On Feb 18, 2008, at 9:14 AM, charlie hunt wrote:
> How about we add this to the Project Grizzly meeting agenda for
> Wednesday?
>
>
That sounds good to me. Since today is a US holiday, I'll respond to
Oleksiy's
email a bit later.
Thanks,
Ken.
> Or, do we believe we are arriving at a conclusion or decision on a
> direction to go?
>
> charlie ...
>
>
> Oleksiy Stashok wrote:
>> Hello Ken,
>>
>>>>>
>>>>> Context... What would be the
>>>>>> BEST to describe an attribute in a collection, in the context
>>>>>> of grizzly's Context, SelectorHandler, Controller? does it
>>>>>> really a String type? Actually, the way Grizzly using the
>>>>>> *term* attribute is not even appropriate. Why? attribute is
>>>>>> something that describes a specific distinguishable feature of
>>>>>> the particular object (or instance). The way grizzly uses
>>>>>> here is, to store SOME objects and their references, in case
>>>>>> it needs at various scopes. This forces users to "create"
>>>>>> their own strings?keys (to accommodate in) to retrieve the
>>>>>> references.
>>>>>
>>>>> Right. Might not be perfect, but a lot of API use that approach:
>>>>>
>>>>> http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/
>>>>> SSLSession.html
>>>>> http://java.sun.com/javaee/5/docs/api/javax/servlet/
>>>>> ServletContext.html
>>> And all of them suffer a string hash lookup on every attribute
>>> access. That is a String hash computation
>>> and comparison, and these are expensive operations to perform
>>> (possibly multiple times) every time we
>>> read bytes from a channel.
>> Hashcode computation happens just once for String, though
>> comparison could be expensive.
>>
>>> The design tradeoff here is that there should only be a small
>>> number of unique attributes in the system, so that the
>>> AttributedObject arraylists are not too large (say 10-30
>>> attributes, not hundreds). Many other designs are possible,
>>> depending on exactly how a Map<Integer,Object> is implemented,
>>> with the assumption that the keys are small contiguously
>>> allocated non-negative integers. For example, segmented maps
>>> could be used, but then the lookup cost is higher.
>>> Saving space costs time in this case.
>> I like your implementation! Agree, we can have several
>> "AttributeObjectBase"-like implementation, one you have in Corba
>> with ArrayLists, another with Maps for situation, where we can
>> have more attributes.
>> Not sure we need to store type in Attribute? Which role does it play?
>>
>> But in common I like idea very much!
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>>
>>> Ken.
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> <charlie.hunt.vcf>----------------------------------------------------
> -----------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net