Pushed to the dev list (I sent it to Ashish only by mistake)
--- Begin Message ---
On Thu, Feb 4, 2010 at 6:32 PM, Emmanuel LŽcharny <[email protected]> wrote:
> Ashish a écrit :
>>
>> On Thu, Feb 4, 2010 at 3:18 PM, Emmanuel Lecharny <[email protected]>
>> wrote:
>>
>>>
>>> - the write log (messages waiting to be written to the client)
>>>
>>> I'm not convinced that the write log accessors should be a separate
>>> component. In fact, I would rather see that as a part of the service's
>>> state.
>>>
>>
>> Sorry, but I don't get this part completely. Do you mean that
>> IoService ought to have an API which provides direct access to write
>> queue?
>> My knowledge in this part is limited :-(
>>
>
> there are two methods in this Interface which gives you two informations :
> - the number of bytes to write
> - the number of messages to write
>
> those informations are gathered in the IoServiceStatistics class .
>
> What I mean (and I may not have been clear) is that I don't see the added
> value of having those two methods in the service, while we can access them
> through some statistics associated with the service.
>
> I would rather have something like : servcie.getStats() which returns an
> instance of all the gathered statistics.
Agreed on this. Not sure what would I gain by getting number of
messages or bytes to be written.
Its clear now.
>>> Is that correct? Fo I miss something here ?
>>>
>>> Also there is some strange method present in this interface, like
>>> broadcast(). I'm not sure it should be a part of the IoService interface,
>>> but rather moved to IoAcceptor (does it make sense for a Connector to
>>> boradcast a message ?)
>>>
>>
>> I think broadcast() should be part of IoAcceptor, to broadcast a
>> message to all active session. Don't think it makes sense to have it
>> for Connector.
>>
>
> I agree.
>>
>> Also, what abt the "IoSessionDataStructureFactory", do we need an API
>> for plugging in this stuff?
>>
>
> Well, I think it has been added in order to allow the programmer to define a
> specific data structure to manage the session's attachements, instead of
> using a simple Map to store the attributes.
>
> Not sure it makes sense, when the programmer can perfectly well store its
> own data structure as an attribute in the session. I think we can get rid of
> that.
Well it would have been good thing, but at this moment its an overkill.
I am not sure if anyone has ever added a custom Session DS.
--
thanks
ashish
--- End Message ---
