directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [mina] Introducing the New API for 0.9.1.
Date Wed, 25 Jan 2006 14:19:51 GMT
2006/1/25, Jose Alberto Fernandez <>:
> 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

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?

what we call human nature is actually human habit
PGP Key ID: 0x854B996C

View raw message