Again, it's all the same protocol, so we're using the same filters on the connector, so there's not much reason to multiple connectors, we simply need multiple handlers. Part of the reason for doing it this way as well was because this was an existing architecture before we started using MINA to handle the actual connections, so it was a matter of fitting it best to MINA.
Again, I don't really care if the SingleSession stuff is removed from MINA as we'll just re-implement it easily enough ourselves. But there IS a use for doing it on the handler side rather than multiple connectors. Also, as an aside, I believe there's no hashmap involved in the multiton here...I believe each handler is simply put as an attribute on each session. On Wed, Mar 11, 2009 at 11:47 AM, Emmanuel Lecharny <[email protected]> wrote: > Squee wrote: >> >> Well, I'd have to go look at the code again to be fully sure, but we >> have a client layer built on top of MINA for the GUI part of our app, >> where we pull a ton of data from a remote server for viewing. When a >> GUI element needs data for its local cache, it creates a "DataChannel" >> object which performs the necessary connections with MINA. > > Why don't you use a Connector for that ? >> >> It then >> synchronously waits for the session to connect before continuing. > > The Connector is just handling that for you ... >> >> The >> DataChannel class is a SingleSessionIoHandler implementation, and our >> IoHandler is a SingleSessionIoHandlerDelegate. Each DataChannel >> subclass provides different IoHandler functionality (same protocol, >> different roles and data to manage). >> > > Why not using a Connector for each protocol ? >> >> This allows us to have completely different handlers for the different >> data caches, while still using the same protocol messages for each >> cache. (i.e. a response from the server to clear the local cache is >> exactly the same, but handled differently depending on the data) This >> is preferable in this instance over the demuxing for this reason, as >> well as the encapsulation that having all of our data handling on our >> DataChannel IoHandlers helps with. >> >> The biggest problem I had with it was that I had to subclass >> SingleSessionIoHandlerDelegate to allow us to use our already created >> DataChannel class (again, an implementation of >> SingleSessionIoHandler), rather than creating them AFTER the session >> was created, but that's probably very specific to our way of using it. >> Basically, our version doesn't use the factory and sets the session on >> an existing specified SingleSessionIoHandler when the session is >> created. >> > > IMO, the 'multiton' pattern is not the best pattern ever. It's just a > Hashmap containing many singleton. I don't see any advantage of having such > a pattern implemented in MINA core. > > I don't mean that what you do is bad, Squee, what I just want to stress is > that it's more or less the application designer to decide what to do with > established connections, but it's not MINA responsability to implement any > existing patterns. > > So, my question is : how hard would it be to switch to a multiton pattern to > a simple map of Connectors ? > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
