Generalization of SEDA

[Trustin Lee <tr...@gmail.com>]

Alex and me talked about EventRouter and its implementation.  SEDA is
a generic event processing framework with multi-layed thread pool, so
routing events between stages is important.  So I suggest the
separation of SEDA core and SEDA network extension now.  The possible
package name would be 'org.apache.seda' and
'org.apache.seda.extension.network'.

I think it is mandatory to do it now because doing so is relatively
cheap and the net effect is very good.  Moreover UDP implementation is
being delayed because of its natural difference from TCP (the
borderline between listener and input stage is ambiguous), so we can
proceed the separation while discussing the UDP issue.  Of course I
can post a patch for this.

How do you think?

Trustin
-- 
what we call human nature in actually is human habit
--
http://gleamynode.net/

Re: Generalization of SEDA

[Alex Karasulu <ao...@bellsouth.net>]

On Tue, 2004-09-21 at 01:29, Trustin Lee wrote:
> Alex and me talked about EventRouter and its implementation.  SEDA is
> a generic event processing framework with multi-layed thread pool, so
> routing events between stages is important.  So I suggest the
> separation of SEDA core and SEDA network extension now.  The possible
> package name would be 'org.apache.seda' and
> 'org.apache.seda.extension.network'.

I'm fine with creating extra packages to start to factor out the network
stuff.  However I don't understand what you mean above in terms of
extensions.  Can you elaborate?

> I think it is mandatory to do it now because doing so is relatively
> cheap and the net effect is very good.  Moreover UDP implementation is
> being delayed because of its natural difference from TCP (the
> borderline between listener and input stage is ambiguous), so we can
> proceed the separation while discussing the UDP issue.  Of course I
> can post a patch for this.

I can take a look at it if you attach this to the JIRA sure.

Alex

Re: Generalization of SEDA

[Nicola Ken Barozzi <ni...@apache.org>]

Trustin Lee wrote:
> Alex and me talked about EventRouter and its implementation.  SEDA is
> a generic event processing framework with multi-layed thread pool, so
> routing events between stages is important.  So I suggest the
> separation of SEDA core and SEDA network extension now.  The possible
> package name would be 'org.apache.seda' and
> 'org.apache.seda.extension.network'.

Careful about not using the org.apache.subproject convention in 
packages, I would strongly suggest 'org.apache.directory.seda' instead.

Avalon did it once for logging and it created only confusion.

Besides, if Apache starts an indipendent project called 'seda', there 
would be naming clashes between the project artifacts.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

RE: Generalization of SEDA

["Noel J. Bergman" <no...@devtech.com>]

Before this discussions goes much further, I'd like to remind everyone of
the prior history and discussions:

http://nagoya.apache.org/eyebrowse/BrowseList?listName=directory-dev@incubat
or.apache.org&by=thread&from=581520

Not to change direction, but to level set, particularly on expectations and
the potential for reuse within the ASF.  Nicola Ken is right to be careful
about package names, but there is every possibility that, done right, this
could be broadly used across the ASF.

So let's make sure that as we develop this, and as the vapor gells into
something very real and functional, that we keep folks like Craig, Berin,
folks from Axis, and elsewhere in the loop.  It should be developed here.
Taking reusable code too soon from its nest because there is the possibility
that it could be reused often kills the project.  So let's be inclusive, and
invite them to participate here.

	--- Noel