I think we need to define better how is it that we want MINA to be
configured and used. When people use the Spring approach, they
definitely want to be in control of the objects they create and of the
scope of those objects in the system. Singletons are a no-no on that
regard. It should be up to the Spring configuration to decide whether an
object should be a singleton or not.
We already discussed on singleton issues and we'll provide a non-singleton way.
On the same vein, when we compose a system out of different components,
we also want to maintain unknown interactions of the components to a
minimum.
What is the 'unknown interaction' here? I don't think we cause any unknown interaction. Besides adding a thread pool by default, what IoService does is almost the same with the code that configures your acceptors and connectors manually.
I did not fully like SimpleServiceRegistry in particular because it had
endless amounts of methods depending on the kind of service one wanted,
but at least when one called unbindAll() I knew the scope of what was
been unbound. I would like IOService to work the same way in that
regard. The only thing I would be willing to have statically is some
registry of all the IOServices currently available, to be able to do
global management. Something like:
/**
* Creates if necessary and returns the IOService instance of that
name
*/
public static IOservice getInstance(String name);
/**
* List all the current active IOService instances
*/
public static IOService[] listInstances();
It would be nice if we have this kind of feature, but do we really need these registry methods? Is the 'name' an ID of IoService instance?
Here I am a little ambivalent. I am all for type safety. But I like the
simplicity of addressing using a URI and being able to pass parameters
at the same time. On the other hand, the objects returned by the methods
should be manageable using set/getters, which means for each type of URI
one should define a proper interface that define all its properties. The
URL parameters can be simply introspected on the setters.
I didn't get what you're saying. Could you give me an example?
I see no reason why we cannot have something very similar to the URL
model, where you first get a subclass of IOConnector (for example) with
any parameters in the URL already set, and then one does
IOConnector.connect (IOHandler), or something like that. Users can in
between downcast to an specific interface and change properties
programmatically if they want to, but it is not necessary.
Could you give me some example code here, too?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
