Re: [MINA 3.0] IoService definition
On 2/10/10 11:24 PM, Alan D. Cabrera wrote: On Feb 10, 2010, at 2:08 PM, Emmanuel Lecharny wrote: On 2/10/10 10:42 PM, Alan D. Cabrera wrote: On Feb 4, 2010, at 1:48 AM, Emmanuel Lecharny wrote: Hi, some more thoughts, as I'd like to define precisely what is an IoService. Looking at the existing code, I would define an IoService as a base Interface for Acceptor and Connector, describing the relationship between all their components, namely : - the chain - the handler - the configuration - a state (active/not active, number of sessions, is the service is disposed, or being disposed...) - 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. 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'm not a big fan of tightly coupling the Acceptor and Connector via a base interface IoService unless there's a concrete and compelling use case where I would want to interchangeably use either. The thing is that they are using the exact same mechanisms, the only big difference is that one initiate the connection, the other one accept them. But we may see more difference if we look in detail. I think that I can correctly restate your words as: The methods in the parent interface, IoService, that would be shared by the Acceptor and Connector have the same semantics. This is why it makes sense to me to push the methods into IoService and have them shared. If my re-wording is correct then I am going to still hold on to my point. An interface should not be used as an indicator for implementation. Which, imo, is the justification you give. To my mind an Acceptor and Connector live in two different worlds and one would never pass around both willy nilly using the base interface. Maybe there's a use case for doing so. I cannot think of one off the top of my head. I will have another look at what we have, and rehash what you said. My battery is dying, and my computer will shutdown soon. I'm also fried, having slept only 5 hours for days... I also think that the modus operandi for the API redesign is to start w/ apps first, generate interfaces that support those apps, then fill in the guts. Starting with the existing API tends to limit the possible ideas and one tends to accidentally bring in some of the less worthwhile bits. Here, I would slightly disagree, if we want to stay close t what we currently have to ease migration. Imho, the vein of ideas that influenced v1.x and v2.x has run its course. v2.x was an attempt to "remedy" the issues of v1.x but, imho, things got way more complicated and bloated. This is why I was thinking of a radical departure. More or less, I agree, but I think that despite the major concerns we have with MINA, the current API is quite good. Anyway, as we are not too 'tainted' with the current code, we can really move on and start thinking about something better and new. If you want to keep backwards compatibility then why not do it in the 2.x branch? I'm not sure I want to spend more time than necessary to fix MINA 2.0. It's too cryptic... -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: [MINA 3.0] IoService definition
On Feb 10, 2010, at 2:08 PM, Emmanuel Lecharny wrote: On 2/10/10 10:42 PM, Alan D. Cabrera wrote: On Feb 4, 2010, at 1:48 AM, Emmanuel Lecharny wrote: Hi, some more thoughts, as I'd like to define precisely what is an IoService. Looking at the existing code, I would define an IoService as a base Interface for Acceptor and Connector, describing the relationship between all their components, namely : - the chain - the handler - the configuration - a state (active/not active, number of sessions, is the service is disposed, or being disposed...) - 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. 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'm not a big fan of tightly coupling the Acceptor and Connector via a base interface IoService unless there's a concrete and compelling use case where I would want to interchangeably use either. The thing is that they are using the exact same mechanisms, the only big difference is that one initiate the connection, the other one accept them. But we may see more difference if we look in detail. I think that I can correctly restate your words as: The methods in the parent interface, IoService, that would be shared by the Acceptor and Connector have the same semantics. This is why it makes sense to me to push the methods into IoService and have them shared. If my re-wording is correct then I am going to still hold on to my point. An interface should not be used as an indicator for implementation. Which, imo, is the justification you give. To my mind an Acceptor and Connector live in two different worlds and one would never pass around both willy nilly using the base interface. Maybe there's a use case for doing so. I cannot think of one off the top of my head. I also think that the modus operandi for the API redesign is to start w/ apps first, generate interfaces that support those apps, then fill in the guts. Starting with the existing API tends to limit the possible ideas and one tends to accidentally bring in some of the less worthwhile bits. Here, I would slightly disagree, if we want to stay close t what we currently have to ease migration. Imho, the vein of ideas that influenced v1.x and v2.x has run its course. v2.x was an attempt to "remedy" the issues of v1.x but, imho, things got way more complicated and bloated. This is why I was thinking of a radical departure. If you want to keep backwards compatibility then why not do it in the 2.x branch? I invite people to look at my HTTP code in my sandbox where I am sketching out some ideas of a possible mina 3 API. It's a sketch and there's a ton of bits that have not even been thought off. I welcome your comments. Sure, will do. Many thanks. Please be genteel with your comments. ;) Regards, Alan
Re: [MINA 3.0] IoService definition
On 2/10/10 10:42 PM, Alan D. Cabrera wrote: On Feb 4, 2010, at 1:48 AM, Emmanuel Lecharny wrote: Hi, some more thoughts, as I'd like to define precisely what is an IoService. Looking at the existing code, I would define an IoService as a base Interface for Acceptor and Connector, describing the relationship between all their components, namely : - the chain - the handler - the configuration - a state (active/not active, number of sessions, is the service is disposed, or being disposed...) - 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. 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'm not a big fan of tightly coupling the Acceptor and Connector via a base interface IoService unless there's a concrete and compelling use case where I would want to interchangeably use either. The thing is that they are using the exact same mechanisms, the only big difference is that one initiate the connection, the other one accept them. But we may see more difference if we look in detail. I also think that the modus operandi for the API redesign is to start w/ apps first, generate interfaces that support those apps, then fill in the guts. Starting with the existing API tends to limit the possible ideas and one tends to accidentally bring in some of the less worthwhile bits. Here, I would slightly disagree, if we want to stay close t what we currently have to ease migration. I invite people to look at my HTTP code in my sandbox where I am sketching out some ideas of a possible mina 3 API. It's a sketch and there's a ton of bits that have not even been thought off. I welcome your comments. Sure, will do. -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: [MINA 3.0] IoService definition
On Feb 4, 2010, at 4:43 AM, Ashish wrote: On Thu, Feb 4, 2010 at 3:18 PM, Emmanuel Lecharny wrote: Hi, some more thoughts, as I'd like to define precisely what is an IoService. Looking at the existing code, I would define an IoService as a base Interface for Acceptor and Connector, describing the relationship between all their components, namely : - the chain - the handler - the configuration - a state (active/not active, number of sessions, is the service is disposed, or being disposed...) - 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 :-( 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. Looking at the current implementation of broadcast and am wondering why it's in the library. It seems very application specific. What is the use case for this? I'm sure there is one, it just doesn't come to mind for me atm. Also, what abt the "IoSessionDataStructureFactory", do we need an API for plugging in this stuff? I think that configuration and session attributes should be merged into a single first class mechanism. It will make the API simpler, WDYT? Regards, Alan
Re: [MINA 3.0] IoService definition
On Feb 4, 2010, at 1:48 AM, Emmanuel Lecharny wrote: Hi, some more thoughts, as I'd like to define precisely what is an IoService. Looking at the existing code, I would define an IoService as a base Interface for Acceptor and Connector, describing the relationship between all their components, namely : - the chain - the handler - the configuration - a state (active/not active, number of sessions, is the service is disposed, or being disposed...) - 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. 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'm not a big fan of tightly coupling the Acceptor and Connector via a base interface IoService unless there's a concrete and compelling use case where I would want to interchangeably use either. I also think that the modus operandi for the API redesign is to start w/ apps first, generate interfaces that support those apps, then fill in the guts. Starting with the existing API tends to limit the possible ideas and one tends to accidentally bring in some of the less worthwhile bits. I invite people to look at my HTTP code in my sandbox where I am sketching out some ideas of a possible mina 3 API. It's a sketch and there's a ton of bits that have not even been thought off. I welcome your comments. Regards, Alan
[Fwd: Re: [MINA 3.0] IoService definition]
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 wrote: > Ashish a écrit : >> >> On Thu, Feb 4, 2010 at 3:18 PM, Emmanuel Lecharny >> 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 ---
Re: [MINA 3.0] IoService definition
On Thu, Feb 4, 2010 at 3:18 PM, Emmanuel Lecharny wrote: > Hi, > > some more thoughts, as I'd like to define precisely what is an IoService. > > Looking at the existing code, I would define an IoService as a base > Interface for Acceptor and Connector, describing the relationship between > all their components, namely : > - the chain > - the handler > - the configuration > - a state (active/not active, number of sessions, is the service is > disposed, or being disposed...) > - 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 :-( > > 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. Also, what abt the "IoSessionDataStructureFactory", do we need an API for plugging in this stuff? > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > > -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
