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 Fri, 27 Jan 2006 03:00:27 GMT
Now I see your point.  Thanks!

Trustin

2006/1/26, Jose Alberto Fernandez <jalberto@cellectivity.com>:
>
>
>
>
>   ------------------------------
>
> *From:* Trustin Lee [mailto:trustin@gmail.com]
>
>  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.
>
>
>
> For example:
>
>    Component A does: IOService.connect(…..); (Maybe more than once)
>
>
>
>    Component B independently does: IOService.connect(….); (maybe more than
> once)
>
>
>
> Now component A decides to go away and shut itself down:
> IOService.unbindAll();
>
> Ups, Component B just lost all its connections and does not know about it.
>
>
>
> These are unknown interactions due to the usage of a singleton.
>
>
>
>
>
> 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?
>
>
>
> As I said, maybe they belong on some factory. The reason for having
> something like this is management. You have a system build by several
> components that can independently be using MINA. But you still want a way to
> tell everyone to shutdown when you want the system to go down. As the server
> will stay alive until all the IOServices finish, you need a way to tell them
> to shut down gracefully.
>
>
>
> These are just loose ideas, not an API. Maybe what is needed is a
> notification mechanism. Something like:
>
>
>
> public static IOService getInstance(UnbindListener listener);
>
>
>
> public static void shutdownIOServices();
>
>
>
> public interface UnbindListener {
>
>
>
>     void unbind(IOConnector);
>
>     void unbind(IOAcceptor);
>
> }
>
>
>
> In this model, when you obtain an IOService you provide a listener where
> the component will receive notifications of connections being terminated and
> hence has a chance to update its state accordingly. Each component can do as
> it see fits, and will only be notified about things created by his own
> 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 do not have your code in front of me so this is just from what I
> understood from reading the messages on this thread.
>
>
>
> So you have different types of URLs:
>
>
>
> String  url = "
> nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=20&receiveBufferSize=4096",
>
>
>
> You get from your IOService instance a URL-like object, x (or y), already
> introspected to set the parameters passed in the URL.
>
>
>
>    IOAcceptor x = ioService.getAcceptor(url);
>
>
>
>    IOConnector y = ioService.getConnector(url);
>
>
>
> After that, you could set more properties programmatically by downcasting
> to the correct type (interface) specific to the URL you requested.
>
>
>
>    ((IOSocketAcceptor) x).setXYZ(….);
>
>
>
> Now you can call on the object to actually perform the connection or
> binding, passing the handlers and filters.
>
>
>
>   x.bind(filterBuilder, handler);
>
>
>
>   y.connect(filterBuilder, handler);
>
>
>
> Jose Alberto
>
>
>



--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
Mime
View raw message