directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Tence <vte...@pyxis-tech.com>
Subject RE: [eve] Event Manager
Date Thu, 04 Dec 2003 22:37:06 GMT
<snip/>
> > You could have a look at the implementation of this pattern I
> > mentioned in a previous mail. At least you'll save yourself
> > a lot of javadoc ;-).
>
> Does it follow the conventions in the link you already sent?

Yes it does.

> I already see several things I can take and add to the existing
> implementation with your permission of course.

> Looks as though Vince you hit the synchronous verse asynchronous
> question before me.  We should stick to synchronous notification
> and use the same trick with a asynchronous event manager as a subscriber.

That's the trick. The asynchronous event manager republishes event on
the bus asynchronously through a queue. It uses a CricularEventFilter
to avoid receiving events the events it has republished.

> Here's the link to that doc again and to Vincent's sf.net effort:
>
> http://members.ispwest.com/jeffhartkopf/notifier/

Here's the implementation:

http://cvs.sourceforge.net/viewcvs.py/d-haven/guiapp/guiapp-core/src/java/or
g/d_haven/guiapp/eventbus/

You will need to remove the Swing related stuff (only a couple of lines
though).

> For the time being we'll model the service using Avalon life-cycle
> methods and target Merlin.  Slowly as we begin to get leads for the Pico,
> Loom, and Phoenix containers we can add adapters for them.
> I don't want to waste too much time messing with containers but have
> their adapters prepared in the background.  I'm thinking Vincent you're
> Pico container proficient

If you say so ;-0

> so you go ahead and get a Pico adapter
> setup for
> it if you like or when you have the time.

I will learn tips and tricks of Picoyification on the AAA bits
and then we can apply all over.

> However we will stick to Merlin
> as the primary and add support for other containers in the background.
> This is just because the rest of the code is based on Merlin and I don't
> want to halt development for the time being.
>
> Container conversations should be minimized just to achieve
> interoperability.  We need to support all of them and will maintain a
> neutral stance towards them all without having any favorites.
>
> I'm dedicated to supporting as many containers as possible but I would
> like to prevent this project from becoming a container discussion list.
> These conversations can be had on the avalon or jcontainer lists.

Sensible approach.

- Vincent


Mime
View raw message