directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
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 <jalberto@cellectivity.com>:
>
> 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?

Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C

Mime
View raw message