You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2003/12/03 01:44:49 UTC
Frontend redesign
Guys,
Here are the topics of discussion:
1). Service decoupling using a centralized event manager service
2). The SEDA stages, events and processing pathway
3). Session handling, identity and synchronization
4). Interactions with server side JNDI provider
1). Service Decoupling Using an EventManager
============================================
First of all it makes sense to use a central event
manager as the hub for delivering events from one
stage or just one service to another. What do I mean
by that?
Within the server, SEDA events must be delivered from sources
to sinks. Each stage is modeled as a service in the server.
Obviously we're going to have the following basic stage flow
for handling a state full client's request response sequence:
input --> decode --> process
|
|
output <-- encode <------/
These points represent the request processing stages. Now
an event in one stage upstream enqueues onto the queue of the
stage downstream creating dependencies between these services
which are SEDA stages. Hence the request processing pathway
looks like one of the service dependency chains within the
server.
Now this is not a problem if we did not have the other services
like the listener and the session manager in the picture which
introduce cycles in the dependency graph. These services are
not Stages in the SEDA sense but they do emit events that are
listened to by other stages.
If we use a central event manager to enable communication
between all the services through events SEDA based or not then
we can turn the dependency graph into a simple tree with the
event manager at the root with one level of children. All
services have a dependency on the event manager. I realized
that this was the direction I wanted to go towards in past
designs but I got mixed up in SEDA verses non-SEDA events.
At the end of the day it does not matter what the nature of the
event is. A central event router or manager can be used to
decouple stages and non-stage services. This way we can do away
with methods on the service interfaces which really do not need
to be exposed. The event handler interfaces are enough for
most generic services and for services that are SEDA stages the
enqueue interface method is all you need for these services.
However I think its best to hid this and not expose it as a
service interface. It is best to use explicit listener interfaces
to flag a stage as recieving certain events rather than exposing
a generic stage enqueue() method.
So I think we should have one central event manager that is
used as a hub to route SEDA and non-seda events from service
to service thereby decoupling services and reducing the number
of exposed service interface methods per service. Now let me
give an example using a particular stage to stage coupling.
Take the input-decoder stage coupling for example. Here the input
stage may be the source of InputEvents which carry some chunk if
data read in a non-blocking fashion from the client's PDU. The
Decoder is an InputListener which explicitly processes an
InputEvent using the inputRecieved() listener interface method.
public void inputRecieved( InputEvent an_event ) ;
Now the decoder stage or a InputListener for the decoder would
just enqueue this event onto the decoder's queue and return. But
now let's look at the benefits of using the event manager. First
the input stage fires the InputEvent using a service method on
the EventManager. The event manager synchronously delivers the
event to the target which in this case is the InputListener. There
may be more than one InputListener registered with the EventManager.
So the event is delivered synchronously to the listeners however
the stage listener processes the event asynchronously. The enqueue
operation returns immediately in the listener for the decoder stage.
So synchronous event delivery is really asynchronous for stages.
The input stage service does not depend on the decoder or vice versa.
Both however depend on the EventManager service which is the middleman.
This is all very simple and I probably bored you guys with
the big explanation and the example but I wanted to make sure I
communicated this simple idea completely.
2). The SEDA stages, events and processing pathway
==================================================
This is now really simple. A SEDA event is just like any other
simple vanilla event. Except the difference is the nature of the
sink makes the event handling semantics asynchronous yet the order
of event processing is preserved by the stage's queue.
The processing pathway was already covered above so there is not
much that's left to be said here.
3). Session handling, identity and synchronization
==================================================
For the time being presume the server only does a simple bind
to establish the clients identity.
Basically the socket connection almost represents the session.
I say this because another bind operation on an already bound
or anonymous user session results in session destruction and
replacement without dropping the socket connection. Not a big
deal. And all the session really is, is a hash table with some
extra session specific parameters like the time the session was
established et cetera.
Now socket connections and IO streams previously were managed
using a unique client key which contained various pieces of info
specific to the socket connection. In fact the actual key is
constructed from parts of the connection parameters like client
host, port to server host port et cetera. Note that his key
carries with it an input synchronization object and an output
synchronization object. This enables two stages to synchronize
on a socket channel if they need to. Also client keys can expire
to represent the fact that the connection was dropped.
The session object returns the ClientKey. Previously I tried not
to expose too much in the ClientKey. Namely I tried to avoid
carrying the socket with the key or exposing access to the socket
the key represents. Now I just gave in temporarily and allowed
for access to the socket. This might be a bad move but it allowed
me to just package the client's Session or the key in events to
pass things around. At first I said I should pass around the socket
in the event rather than keep it in the key. This way I can give the
key to untrusted code without comprimising the socket and this
I think must be the case. We should discuss this detail.
Now keep in mind that for nonblocking IO the getChannel() call on
a socket returns a non-null channel. For blocking IO or sockets
created using methods other than through channel construction, the
returned channel is null. So we can just give a stage that needs to
work on a socket channel the socket. This means stages can detect
the nature of events and determine if they will handle it or not.
So a NonBlockingInputManager (input stage) is an implementation that
handles channel based non-blocking IO. Other implementations of the
InputManager can just handle blocking IO. We can have both residing
within the same server. For the time being SSL connections can
leverage the blocking IO stages rather than the NIO based ones until
SUN adds SSL support to the nio stuff.
So to summarize we need to determine if we keep the ClientKey
concept, how we manage protecting the socket when the code is
not trusted. Should we hide the socket or just carry it in a
event. Or is it best to have a service that enables access to
the socket based on the (old implementation) and we protect the
access to the service rather than the key.
4). Interactions with server side JNDI provider
===============================================
Now this is the cool stuff. We will be replacing the old
code that directly accessed the backend nexus: the big
mama jama backend that all backends hung off of. In its
place we shall have request processors/handlers that use
JNDI and the server side LDAP JNDI provider to access the
nexus.
Just as a heads up there is an interceptor framework in
the backend between the JNDI provider and the nexus which
inject several services to spare backend developers from
having to implement.
Continuing on the JNDI provider is used to make calls
against the backend subsystem which is detachable from
the front end completely and can run in isolation without
a front end. In the begining there is a bind operation
that establishes session. This operation may need to access
the backend to authenticate. A separate service is designed
to abstract away this access. I say "may need" above because
later when SASL is enabled access to certificate stores or
Kerberos tickets may occur outside of the server. But presume
that this stuff is built into Eve or the authentication is
simple and the authentication profile resides on a backend.
To get at this information the credentials of the user on
a simple bind attempt must be looked up using JNDI and
it must be determined if the user is authorized or not.
If the backend operates in stand alone mode then do we support
authentication there and simply have the frontend use the
standard JNDI based means to pass credential information to the
provider. Or should the provider not care so long as a principle
is present within the environment passed to the initial context.
Note that if authentication is to occur within the provider we
want to avoid having to do it for each request. Basically this
is a matter of associating front-end session with the provider.
Basically the JNDI provider tracks session via the Context. If
the InitialContext passes then that means the users identity is
known and all other contexts there after inherit the identity.
Now if authorization is not conducted within the backend subsystem
then there has to be a way to pass identity down into it and this
could be a matter of passing a principle within the environment.
However keep in mind that with stored procedures and triggers
the developer will have access to these contexts. They need access
to determine what the subject of an operation is. To preserve
security then access to these security objects must be protected.
Basically identity theft (impersonation) is possible.
So lots of things here to think about before the front end
redesign can occur.
Alex
Re: [eve] Event Manager
Posted by Stephen McConnell <mc...@apache.org>.
Wes McKean wrote:
>I really like the Event Notifier Pattern. May I take a stab at this? If so,
>should I write it for Merlin? Or should I create something generic that can
>be imbedded in any container? The container could then implement a standard
>interface or something.
>
What Avalon has been working towards is the general minimization of the
concern that a component has with respect to the container that it is
running within. You will need to follow some rules - for example if you
need access to resources (such as a working directory) then you need to
use establish Avalon resource names and the @avalon javadoc tags.
Providing you stick with the avalon contract you should not have any
trouble running your component in other containers because they all
claim to support Avalon.
If you need any help on the Merlin container just yell out and I can
give you a hand - or if you want just post a message over on dev@avalon
where a couple of hundred people are lurking around and amongst them is
a lot of Merlin experience.
Cheers, Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
RE: [eve] Event Notification Service ( Was Event Manager )
Posted by Alex Karasulu <ao...@bellsouth.net>.
Wes,
The aspect stuff is actually unrelated and reside within the backend
subsystem which is separate from the frontend discussion. I'll post
and email right after this one on the interceptor framework within the
backend subsystem just to clarify.
Alex
> -----Original Message-----
> From: Wes McKean [mailto:wmckean@logictrends.com]
> Sent: Friday, December 05, 2003 2:00 PM
> To: Apache Directory Developers List
> Subject: Re: [eve] Event Notification Service ( Was Event Manager )
>
> Cool. So we are going to implement a synchronous event queue, and provide
> an
> Asychronous attachment, if thats what we decide we need.
>
> Question: Are we still planning on doing the before and after channels
> with
> AspectJ? If so, how does that fit into this architecture?
>
> Wes
>
>
> On Thursday 04 December 2003 11:49 pm, Alex Karasulu wrote:
> > Looks like Wes we get to implement this stuff anyway. It will
> > be more fun I think.
> >
> > Anyway I'm done massaging the old LDAPd projects that just got
> > imported and don't think I can get them to fully build and deploy
> > using phoenix with the new maven stuff without wasting more time.
> > The problem has to do with the sar building etc.
> >
> > Instead I'd rather focus on this stuff and leave it as is. We can't
> > release it until we're out of the incubator anyway.
> >
> > So what I did was this. I created a directory/ldap/eve parent and
> > under that created the frontend and backend directories. Basically
> > these are the two major subsystems within the server.
> >
> > All our components should be built as separate maven projects unless
> > Brett has objects :-). For example the event stuff would be a project
> > under directory/ldap/eve/frontend/event and so on.
> >
> > I will start moving some of my code from the sandboxs here as well as
> > the new things I've been exploring locally with the frontend.
> >
> > Alex
Re: [eve] Event Notification Service ( Was Event Manager )
Posted by Wes McKean <wm...@logictrends.com>.
Cool. So we are going to implement a synchronous event queue, and provide an
Asychronous attachment, if thats what we decide we need.
Question: Are we still planning on doing the before and after channels with
AspectJ? If so, how does that fit into this architecture?
Wes
On Thursday 04 December 2003 11:49 pm, Alex Karasulu wrote:
> Looks like Wes we get to implement this stuff anyway. It will
> be more fun I think.
>
> Anyway I'm done massaging the old LDAPd projects that just got
> imported and don't think I can get them to fully build and deploy
> using phoenix with the new maven stuff without wasting more time.
> The problem has to do with the sar building etc.
>
> Instead I'd rather focus on this stuff and leave it as is. We can't
> release it until we're out of the incubator anyway.
>
> So what I did was this. I created a directory/ldap/eve parent and
> under that created the frontend and backend directories. Basically
> these are the two major subsystems within the server.
>
> All our components should be built as separate maven projects unless
> Brett has objects :-). For example the event stuff would be a project
> under directory/ldap/eve/frontend/event and so on.
>
> I will start moving some of my code from the sandboxs here as well as
> the new things I've been exploring locally with the frontend.
>
> Alex
RE: [eve] Event Notification Service ( Was Event Manager )
Posted by Alex Karasulu <ao...@bellsouth.net>.
Looks like Wes we get to implement this stuff anyway. It will
be more fun I think.
Anyway I'm done massaging the old LDAPd projects that just got
imported and don't think I can get them to fully build and deploy
using phoenix with the new maven stuff without wasting more time.
The problem has to do with the sar building etc.
Instead I'd rather focus on this stuff and leave it as is. We can't
release it until we're out of the incubator anyway.
So what I did was this. I created a directory/ldap/eve parent and
under that created the frontend and backend directories. Basically
these are the two major subsystems within the server.
All our components should be built as separate maven projects unless
Brett has objects :-). For example the event stuff would be a project
under directory/ldap/eve/frontend/event and so on.
I will start moving some of my code from the sandboxs here as well as
the new things I've been exploring locally with the frontend.
Alex
RE: [eve] Event Manager
Posted by "Noel J. Bergman" <no...@devtech.com>.
Vincent Tence wrote:
> I am not really aware of licensing stuff obviously. I think Berin and I
> have been the only contributors to that code
None of the other people listed have actually contributed code? That works,
too. We just need to get your CLA on file, which we'll need along with the
software grant for the AAA codebase.
--- Noel
RE: [eve] Event Manager
Posted by Vincent Tence <vt...@videotron.ca>.
I am not really aware of licensing stuff obviously. I think Berin and I
have been the only contributors to that code, but as Alex said, it's
pretty small and straightforward anyway. The most value lies in the
javadoc (2 or 3 times more doc than code I guess). Is there any issue
copying the doc?
- Vincent
On Fri, 2003-12-05 at 04:43, Noel J. Bergman wrote:
> > In the beginning I thought it was do-able since the project uses
> > the Apache license and all the members were Apache people or about
> > to be Apache people but I should stop presuming things.
>
> Actually, I read Brian's message as saying that because they used the Apache
> license without changing the name, we could use it. Also, if all of the
> people had signed CLAs (or do sign), we'd be fine, too. The exposure would
> be from someone who contributed code without a CLA, and then decides to
> complain later. As Brian said:
>
> > Therefore: if the license on d-haven really is either the Apache License
> > or a name-replaced equivalent, it is not mandatory to get CLAs from every
> > contributor. It is *preferred* that we get those, so as to provide a
> > second layer of defense should anyone make noise about it.
>
> So your example above would allow re-use.
>
> --- Noel
>
RE: [eve] Event Manager
Posted by Alex Karasulu <ao...@bellsouth.net>.
Don't worry Wes this is totally due to the fact that
the ball has started rolling and everything is new. I
also am trying to get as much information out to people
as possible so just everyone has the knowledge to hack
the code.
It will slow down soon.
Alex
> -----Original Message-----
> From: Wes McKean [mailto:wmckean@logictrends.com]
> Sent: Friday, December 05, 2003 10:01 AM
> To: Apache Directory Developers List
> Subject: Re: [eve] Event Manager
>
> Unfortunately, this list is already generating tons of mail, and I just
> don't
> have the time to read it as thoroughly as I like :-) If you, Alex, or
> Vince
> already has stuff done, then by all means, let's use it. I don't want to
> re-invent the wheel more than three times.
>
> Wes
>
> On Thursday 04 December 2003 11:51 pm, Alex Karasulu wrote:
> > I'm a little dense. It's cool I don't mind reworking it
> > and I'm sure Wes would like that.
> >
> > > -----Original Message-----
> > > From: Noel J. Bergman [mailto:noel@devtech.com]
> > > Sent: Thursday, December 04, 2003 11:43 PM
> > > To: Apache Directory Developers List
> > > Subject: RE: [eve] Event Manager
> > >
> > > > In the beginning I thought it was do-able since the project uses
> > > > the Apache license and all the members were Apache people or about
> > > > to be Apache people but I should stop presuming things.
> > >
> > > Actually, I read Brian's message as saying that because they used the
> > > Apache
> > > license without changing the name, we could use it. Also, if all of
> the
> > > people had signed CLAs (or do sign), we'd be fine, too. The exposure
> > > would
> > > be from someone who contributed code without a CLA, and then decides
> to
> > >
> > > complain later. As Brian said:
> > > > Therefore: if the license on d-haven really is either the Apache
> > > > License or a name-replaced equivalent, it is not mandatory to get
> CLAs
> > > > from
> > >
> > > every
> > >
> > > > contributor. It is *preferred* that we get those, so as to provide
> a
> > > > second layer of defense should anyone make noise about it.
> > >
> > > So your example above would allow re-use.
> > >
> > > --- Noel
Re: [eve] Event Manager
Posted by Wes McKean <wm...@logictrends.com>.
Unfortunately, this list is already generating tons of mail, and I just don't
have the time to read it as thoroughly as I like :-) If you, Alex, or Vince
already has stuff done, then by all means, let's use it. I don't want to
re-invent the wheel more than three times.
Wes
On Thursday 04 December 2003 11:51 pm, Alex Karasulu wrote:
> I'm a little dense. It's cool I don't mind reworking it
> and I'm sure Wes would like that.
>
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> > Sent: Thursday, December 04, 2003 11:43 PM
> > To: Apache Directory Developers List
> > Subject: RE: [eve] Event Manager
> >
> > > In the beginning I thought it was do-able since the project uses
> > > the Apache license and all the members were Apache people or about
> > > to be Apache people but I should stop presuming things.
> >
> > Actually, I read Brian's message as saying that because they used the
> > Apache
> > license without changing the name, we could use it. Also, if all of the
> > people had signed CLAs (or do sign), we'd be fine, too. The exposure
> > would
> > be from someone who contributed code without a CLA, and then decides to
> >
> > complain later. As Brian said:
> > > Therefore: if the license on d-haven really is either the Apache
> > > License or a name-replaced equivalent, it is not mandatory to get CLAs
> > > from
> >
> > every
> >
> > > contributor. It is *preferred* that we get those, so as to provide a
> > > second layer of defense should anyone make noise about it.
> >
> > So your example above would allow re-use.
> >
> > --- Noel
RE: [eve] Event Manager
Posted by Alex Karasulu <ao...@bellsouth.net>.
I'm a little dense. It's cool I don't mind reworking it
and I'm sure Wes would like that.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Thursday, December 04, 2003 11:43 PM
> To: Apache Directory Developers List
> Subject: RE: [eve] Event Manager
>
> > In the beginning I thought it was do-able since the project uses
> > the Apache license and all the members were Apache people or about
> > to be Apache people but I should stop presuming things.
>
> Actually, I read Brian's message as saying that because they used the
> Apache
> license without changing the name, we could use it. Also, if all of the
> people had signed CLAs (or do sign), we'd be fine, too. The exposure
> would
> be from someone who contributed code without a CLA, and then decides to
> complain later. As Brian said:
>
> > Therefore: if the license on d-haven really is either the Apache License
> > or a name-replaced equivalent, it is not mandatory to get CLAs from
> every
> > contributor. It is *preferred* that we get those, so as to provide a
> > second layer of defense should anyone make noise about it.
>
> So your example above would allow re-use.
>
> --- Noel
RE: [eve] Event Manager
Posted by "Noel J. Bergman" <no...@devtech.com>.
> In the beginning I thought it was do-able since the project uses
> the Apache license and all the members were Apache people or about
> to be Apache people but I should stop presuming things.
Actually, I read Brian's message as saying that because they used the Apache
license without changing the name, we could use it. Also, if all of the
people had signed CLAs (or do sign), we'd be fine, too. The exposure would
be from someone who contributed code without a CLA, and then decides to
complain later. As Brian said:
> Therefore: if the license on d-haven really is either the Apache License
> or a name-replaced equivalent, it is not mandatory to get CLAs from every
> contributor. It is *preferred* that we get those, so as to provide a
> second layer of defense should anyone make noise about it.
So your example above would allow re-use.
--- Noel
RE: [eve] Event Manager
Posted by Alex Karasulu <ao...@bellsouth.net>.
Brian,
Thanks for the info it makes a lot of sense. I don't intend
to use this code. It's really straight forward and small in
size so I think we can simply re-implement it using the paper
it was based on. I posted something like this after realizing
the license issue:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=directory-dev@incubator.
apache.org&msgNo=317
In the beginning I thought it was do-able since the project uses
the Apache license and all the members were Apache people or about
to be Apache people but I should stop presuming things.
Thanks again,
Alex
> -----Original Message-----
> From: Brian Behlendorf [mailto:brian@collab.net]
> Sent: Thursday, December 04, 2003 10:57 PM
> To: licensing@apache.org
> Cc: Apache Directory Developers List; bloritsch@apache.org
> Subject: RE: [eve] Event Manager
>
>
> It is most preferable to have CLAs or software grants from everyone who
> has touched code we are importing into apache.org CVS, there is no doubt
> about that.
>
> It is not absolutely mandatory, however, so long as the pre-existing
> license on that code grants the necessary rights for a CLA-signing ASF
> commiter to commit that codebase to apache.org CVS.
>
> A clear example is Henry Spencer's regex package in the apache-1.3 tree.
> Henry himself has not signed a CLA nor a software grant. However, here is
> his copyright:
>
> http://cvs.apache.org/viewcvs.cgi/*checkout*/apache-
> 1.3/src/regex/COPYRIGHT?rev=HEAD&content-type=text/plain
>
> Note that one can follow all the requirements of their Apache CLA, and the
> terms of Henry's copyright, at the same time, there is no conflict.
>
> This is also why the CLA is not a copyright *assignment*, but simply a
> grant of rights. Alexei Kosut, who checked in Spencer's regex package
> back in 1995, did not have the right to assign "clear title" to the code
> to the ASF, and he didn't need to. Yet, the ASF still can do everything
> it needs to do to Henry's package, namely modify and redistribute under
> terms of our choosing following the terms of Henry's copyright.
>
> Henry's BSD-without-attribution is an easy example; the next easiest to
> look at would be another Apache-licensed product. Let's assume the author
> did the right thing and correctly labeled themselves in the license,
> rather than claiming that it was the Apache Software Foundation that was
> the copyright holder. It appears that we could incorporate such code
> without problems, paying attention to any special terms we couldn't use in
> the name of the derivative work (just like derivative works can't call
> themselves Apache) and giving credit where credit is due. If the authors
> of this non-Apache code didn't replace our names with theirs... then it's
> their loss, not ours.
>
> Therefore: if the license on d-haven really is either the Apache License
> or a name-replaced equivalent, it is not mandatory to get CLAs from every
> contributor. It is *preferred* that we get those, so as to provide a
> second layer of defense should anyone make noise about it.
>
> I am not a lawyer, nor do I pretend to be a final authority on this, but
> this is the the understanding of law under which I would proceed.
>
> Brian
>
>
> On Thu, 4 Dec 2003, Noel J. Bergman wrote:
> > Alex Karasulu wrote:
> >
> > > Then we'll start borrowing from [http://sourceforge.net/projects/d-
> haven/]
> >
> > The license is the Apache Software License, and Berin Loritsch is the
> > project manager, but not all of the contributors are Apache Committers,
> > meaning that they don't have CLAs on file with the Foundation.
> >
> > That makes at least three Avalon-related projects on SourceForge using
> the
> > ASL. Nicola Ken has expressed concern that without a CLA and/or
> software
> > grant, we can't assume that we have clear title to use the code. Due to
> the
> > SCO lawsuit, people are especially sensitive to making sure that title
> is
> > documented and clean.
> >
> > I am cc'ing licensing@, and hopefully we can get some guidance.
> >
> > --- Noel
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: licensing-unsubscribe@apache.org
> > For additional commands, e-mail: licensing-help@apache.org
> >
RE: [eve] Event Manager
Posted by Brian Behlendorf <br...@collab.net>.
It is most preferable to have CLAs or software grants from everyone who
has touched code we are importing into apache.org CVS, there is no doubt
about that.
It is not absolutely mandatory, however, so long as the pre-existing
license on that code grants the necessary rights for a CLA-signing ASF
commiter to commit that codebase to apache.org CVS.
A clear example is Henry Spencer's regex package in the apache-1.3 tree.
Henry himself has not signed a CLA nor a software grant. However, here is
his copyright:
http://cvs.apache.org/viewcvs.cgi/*checkout*/apache-1.3/src/regex/COPYRIGHT?rev=HEAD&content-type=text/plain
Note that one can follow all the requirements of their Apache CLA, and the
terms of Henry's copyright, at the same time, there is no conflict.
This is also why the CLA is not a copyright *assignment*, but simply a
grant of rights. Alexei Kosut, who checked in Spencer's regex package
back in 1995, did not have the right to assign "clear title" to the code
to the ASF, and he didn't need to. Yet, the ASF still can do everything
it needs to do to Henry's package, namely modify and redistribute under
terms of our choosing following the terms of Henry's copyright.
Henry's BSD-without-attribution is an easy example; the next easiest to
look at would be another Apache-licensed product. Let's assume the author
did the right thing and correctly labeled themselves in the license,
rather than claiming that it was the Apache Software Foundation that was
the copyright holder. It appears that we could incorporate such code
without problems, paying attention to any special terms we couldn't use in
the name of the derivative work (just like derivative works can't call
themselves Apache) and giving credit where credit is due. If the authors
of this non-Apache code didn't replace our names with theirs... then it's
their loss, not ours.
Therefore: if the license on d-haven really is either the Apache License
or a name-replaced equivalent, it is not mandatory to get CLAs from every
contributor. It is *preferred* that we get those, so as to provide a
second layer of defense should anyone make noise about it.
I am not a lawyer, nor do I pretend to be a final authority on this, but
this is the the understanding of law under which I would proceed.
Brian
On Thu, 4 Dec 2003, Noel J. Bergman wrote:
> Alex Karasulu wrote:
>
> > Then we'll start borrowing from [http://sourceforge.net/projects/d-haven/]
>
> The license is the Apache Software License, and Berin Loritsch is the
> project manager, but not all of the contributors are Apache Committers,
> meaning that they don't have CLAs on file with the Foundation.
>
> That makes at least three Avalon-related projects on SourceForge using the
> ASL. Nicola Ken has expressed concern that without a CLA and/or software
> grant, we can't assume that we have clear title to use the code. Due to the
> SCO lawsuit, people are especially sensitive to making sure that title is
> documented and clean.
>
> I am cc'ing licensing@, and hopefully we can get some guidance.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: licensing-unsubscribe@apache.org
> For additional commands, e-mail: licensing-help@apache.org
>
RE: [eve] Event Manager
Posted by Alex Karasulu <ao...@bellsouth.net>.
Noel,
No problem this code is very easy and standard issue
we can weave it from the document link in no time.
It will look very similar most likely because of the
fact that the identifiers and structure will adhere
to the document. It's worth doing it.
Thanks for the heads up.
Alex
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Thursday, December 04, 2003 7:29 PM
> To: Apache Directory Developers List
> Cc: bloritsch@apache.org; licensing@apache.org
> Subject: RE: [eve] Event Manager
>
> Alex Karasulu wrote:
>
> > Then we'll start borrowing from [http://sourceforge.net/projects/d-
> haven/]
>
> The license is the Apache Software License, and Berin Loritsch is the
> project manager, but not all of the contributors are Apache Committers,
> meaning that they don't have CLAs on file with the Foundation.
>
> That makes at least three Avalon-related projects on SourceForge using the
> ASL. Nicola Ken has expressed concern that without a CLA and/or software
> grant, we can't assume that we have clear title to use the code. Due to
> the
> SCO lawsuit, people are especially sensitive to making sure that title is
> documented and clean.
>
> I am cc'ing licensing@, and hopefully we can get some guidance.
>
> --- Noel
RE: [eve] Event Manager
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex Karasulu wrote:
> Then we'll start borrowing from [http://sourceforge.net/projects/d-haven/]
The license is the Apache Software License, and Berin Loritsch is the
project manager, but not all of the contributors are Apache Committers,
meaning that they don't have CLAs on file with the Foundation.
That makes at least three Avalon-related projects on SourceForge using the
ASL. Nicola Ken has expressed concern that without a CLA and/or software
grant, we can't assume that we have clear title to use the code. Due to the
SCO lawsuit, people are especially sensitive to making sure that title is
documented and clean.
I am cc'ing licensing@, and hopefully we can get some guidance.
--- Noel
RE: [eve] Event Manager
Posted by Alex Karasulu <ao...@bellsouth.net>.
> <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.
Then we'll start borrowing from it. I just got back and have some
repo things to do to get the old stuff to compile. Then I'm off to
work on the setting up this event stuff which we all can work on.
I'll start pulling over some of your event bus code decoupling it
from the Swing.
> 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.
That's cool - no need to reinvent the wheel (excuse the slight pun).
> > 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).
Great will do.
> > 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.
That sounds like a plan. Hopefully after that I can give a general
Breakdown of the backend setup so we can start Picoyificamationing :-)
there.
Ok we got plans.
Alex
RE: [eve] Event Manager
Posted by Vincent Tence <vt...@pyxis-tech.com>.
<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
RE: [eve] Event Manager
Posted by Alex Karasulu <ao...@bellsouth.net>.
> > I really like the Event Notifier Pattern. May I take a stab at
I'm glad you are excited about it :-). Sure if you want it but
I think I wrote it already but it does not follow the document
identifiers used. If you want to start from scratch or retro
fit stuff then that's cool.
I have the whole event model we need defined however I think its
best we do it as a group going over the events and listeners
rather than one person doing it in isolation. Basically I also
want to capture the discussion about the design in email to a
degree through conversation so I can come back to it for the
documentation.
> > this? If so,
> > should I write it for Merlin? Or should I create something
> > generic that can
> > be imbedded in any container? The container could then implement
> > a standard
> > interface or something.
>
> 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? I
already see several things I can take and add to the existing
implementation with your permission of course.
> > Here's my idea...
> >
> > The Event Manager will establish a queue for the events. I'm
> > thinking one
> > queue is fine, just like in the pattern, although there may be a
> > benefit to
> > using multiple queues ( one for every event type ), please comment.
>
> If you only want asynchronous notification, then a queue is fine.
>
> In the GuiApp framework, we had need for both sync and async event
> processing.
> The implementation we did was synchronous (running in the Swing Event
> thread).
> To get the async functionality, we registered an aysnc event manager as a
> subscriber
> of the event bus, responsible for listening for some of the
> events (the async ones) and enqueuing them for aysnc delivery.
>
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.
Here's the link to that doc again and to Vincent's sf.net effort:
http://members.ispwest.com/jeffhartkopf/notifier/
The best way for us to proceed is to just start going at it. For now let's
all get setup with subversion. I want to start fresh reimplmenting some
parts and moving others from the .../directory/ldap/server folder into a
.../directory/ldap/eve folder in the subversion repository. I want us
together to start going to town on the event package.
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 so you go ahead and get a Pico adapter setup for
it if you like or when you have the time. 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.
Alex
RE: [eve] Event Manager
Posted by Vincent Tencé <vt...@pyxis-tech.com>.
> I really like the Event Notifier Pattern. May I take a stab at
> this? If so,
> should I write it for Merlin? Or should I create something
> generic that can
> be imbedded in any container? The container could then implement
> a standard
> interface or something.
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 ;-).
> Here's my idea...
>
> The Event Manager will establish a queue for the events. I'm
> thinking one
> queue is fine, just like in the pattern, although there may be a
> benefit to
> using multiple queues ( one for every event type ), please comment.
If you only want asynchronous notification, then a queue is fine.
In the GuiApp framework, we had need for both sync and async event
processing.
The implementation we did was synchronous (running in the Swing Event
thread).
To get the async functionality, we registered an aysnc event manager as a
subscriber
of the event bus, responsible for listening for some of the
events (the async ones) and enqueuing them for aysnc delivery.
> There is a single thread monitoring the queue. When an event
> gets placed into
> the queue, the thread picks it up, creates or gets a worker
> thread from the
> pool, then goes through the subscribers, notifying each one of the event.
>
> The subscriber may or may not have its own thread pool. We don't care :-)
>
> Let me know... Looks like it could be fun.
>
> Wes
>
>
RE: [eve] Event Manager
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I really like the Event Notifier Pattern. May I take a stab at this?
FWIW, I like it to ... which is why I wrote an implementation of the CORBA
COS Event Service years ago in C++. Also, Vince pointed to one, which
assuming that the license is compatible, would be at least a start.
> The Event Manager will establish a queue for the events. I'm thinking one
> queue is fine, just like in the pattern, although there may be a benefit
to
> using multiple queues ( one for every event type ), please comment.
An Event Channel, to use COS Event Service terms, manages a particular set
of registered suppliers and consumers. Both pull and push processing are
supported for both suppliers and consumers. How you do that is up to you,
but I found it useful to maintain a queue for each pull consumer.
--- Noel
[eve] Event Manager
Posted by Wes McKean <wm...@logictrends.com>.
I really like the Event Notifier Pattern. May I take a stab at this? If so,
should I write it for Merlin? Or should I create something generic that can
be imbedded in any container? The container could then implement a standard
interface or something.
Here's my idea...
The Event Manager will establish a queue for the events. I'm thinking one
queue is fine, just like in the pattern, although there may be a benefit to
using multiple queues ( one for every event type ), please comment.
There is a single thread monitoring the queue. When an event gets placed into
the queue, the thread picks it up, creates or gets a worker thread from the
pool, then goes through the subscribers, notifying each one of the event.
The subscriber may or may not have its own thread pool. We don't care :-)
Let me know... Looks like it could be fun.
Wes
Re: [eve] RE: Frontend redesign
Posted by Wes McKean <wm...@logictrends.com>.
First of all, I think the current implementation of the front end design in
the old ldapd implementation is fine. That said, I am not against reworking
it.
> That's what we're looking for. I think JMS is close but is overkill
> perhaps but JMS is obviously a specific manifestation of this pattern.
>
I wasn't suggesting using JMS or an internal version of it. I agree that that
is overkill. We need something lightweight and fast. I'll take a look at
those links now.
Wes
RE: [eve] RE: Frontend redesign
Posted by Alex Karasulu <ao...@bellsouth.net>.
Sounds sensible! I'll go with that.
> -----Original Message-----
> From: Vincent Tence [mailto:vtence@pyxis-tech.com]
> Sent: Thursday, December 04, 2003 2:53 PM
> To: Apache Directory Developers List
> Subject: RE: [eve] RE: Frontend redesign
>
> > That reminds me should we talk about multiple listeners or subscribers.
> > What's the difference? In my mind there's nothing that really sticks
> out
> > right now.
>
> It seems to be accepted that listener is used for the basic observer
> pattern,
> listeners know who/where they're listening. Subscribers don't, the're
> merely
> interested in something, not knowing who/where the event comes from.
>
> - Vincent
RE: [eve] RE: Frontend redesign
Posted by Vincent Tence <vt...@pyxis-tech.com>.
> That reminds me should we talk about multiple listeners or subscribers.
> What's the difference? In my mind there's nothing that really sticks out
> right now.
It seems to be accepted that listener is used for the basic observer
pattern,
listeners know who/where they're listening. Subscribers don't, the're merely
interested in something, not knowing who/where the event comes from.
- Vincent
[eve] RE: Frontend redesign
Posted by Alex Karasulu <ao...@bellsouth.net>.
<snip/>
> > However I think its best to hid this and not expose it as a
> > service interface. It is best to use explicit listener interfaces
> > to flag a stage as recieving certain events rather than exposing
> > a generic stage enqueue() method.
>
> Exactly! Take a lesson from the JMS folks and write a lean mean internal
> message driven system. Would not a more appropriate term for this module
> be
> QueueManager, rather than EventManager :-) Seems like we are going to be
> creating and providing access to a number of queues, and modules can
> register
> with each queue to listen for events. I assume that each queue would be
> running in its own thread and distributing events to the appropriate
> registered/concerned parties.
Just to clarify for others:
A Stage has a queue, a handler thread and a thread pool of worker threads.
Stages in Eve implement Startable (Runnable) and are services. The
main handler thread of the SEDA stage implementation pops off events from
the queue and hands off events to the workers which process these events.
In Eve there are a few modules/services that are implemented as stages.
The decoder for example is a stage that processes InputEvents that are
pushed onto its queue.
Basically the enqueue operation of events onto a Stage should be deliverd
through a central service. Again Vincent's link here was great:
http://members.ispwest.com/jeffhartkopf/notifier/
So I quote this page:
"Notice that all publication and subscription is done through the event
service. The event service maintains all information about which subscribers
are interested in which events, so that publishers and subscribers need not
be aware of each other. Moreover, anyone may publish or subscribe to events
using the well-defined interface provided by the event service without
having to implement any special logic to handle interaction with other
entities for which it has no other reason to communicate."
That's what we're looking for. I think JMS is close but is overkill perhaps
but JMS is obviously a specific manifestation of this pattern.
>
> Question: If we are distributing events to registered listeners, is the
> Event
> consumed after all listeners have been notified? I think so.
Yes it is considered consumed.
That reminds me should we talk about multiple listeners or subscribers.
What's the difference? In my mind there's nothing that really sticks out
right now.
<snip/>
> > So to summarize we need to determine if we keep the ClientKey
> > concept, how we manage protecting the socket when the code is
> > not trusted. Should we hide the socket or just carry it in a
> > event. Or is it best to have a service that enables access to
> > the socket based on the (old implementation) and we protect the
> > access to the service rather than the key.
>
> I don't see any reason any reason to protect the client socket. There are
> about a half dozen ways to get to it if you really want to, including
> hacking
> the code :-) By routing the Socket or SocketChannel through the process,
> you
> will avoid having to look it up later, and in my opinion keeps everything
> compact.
Yeah but we're going to need to protect access to it if the key
is ever to be presented to a stored procedure which technically
is not trusted code. It is user code and runs in the server.
For now let's use it and if we need to we can re-factor the code
to protect against access to the socket.
Peter what do you think?
Alex
[eve] RE: Frontend redesign
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Wes McKean [mailto:wmckean@logictrends.com]
> Sent: Thursday, December 04, 2003 11:06 AM
> To: Apache Directory Developers List
> Subject: Re: Frontend redesign
>
> <snip>
> > 1). Service Decoupling Using an EventManager
> > ============================================
> >
>
> I really like the idea of decoupling the services by making everything
> event
> driven. There are quite a few modules lying around that have circular
> dependencies. By doing this, we basically have one dependancy, the
> EventManager, and everything else is event driven.
Take a look at the link that Vincent sent on the event notification
stuff and the project at source forge he has been working on with
Berin. I think this or a variant of it is what we're looking for.
> <snip>
>
> > However I think its best to hid this and not expose it as a
> > service interface. It is best to use explicit listener interfaces
> > to flag a stage as recieving certain events rather than exposing
> > a generic stage enqueue() method.
>
> Exactly! Take a lesson from the JMS folks and write a lean mean internal
> message driven system. Would not a more appropriate term for this module
> be
> QueueManager, rather than EventManager :-) Seems like we are going to be
> creating and providing access to a number of queues, and modules can
> register
> with each queue to listen for events. I assume that each queue would be
> running in its own thread and distributing events to the appropriate
> registered/concerned parties.
>
> Question: If we are distributing events to registered listeners, is the
> Event
> consumed after all listeners have been notified? I think so.
>
> > 2). The SEDA stages, events and processing pathway
> > ==================================================
> >
> > This is now really simple. A SEDA event is just like any other
> > simple vanilla event. Except the difference is the nature of the
> > sink makes the event handling semantics asynchronous yet the order
> > of event processing is preserved by the stage's queue.
> >
> > The processing pathway was already covered above so there is not
> > much that's left to be said here.
> >
>
> A SEDA event is just a different type of event...
>
> >
> > 3). Session handling, identity and synchronization
> > ==================================================
> >
>
> <snip>
>
> >
> > Now keep in mind that for nonblocking IO the getChannel() call on
> > a socket returns a non-null channel. For blocking IO or sockets
> > created using methods other than through channel construction, the
> > returned channel is null. So we can just give a stage that needs to
> > work on a socket channel the socket. This means stages can detect
> > the nature of events and determine if they will handle it or not.
>
> When using a non-blocking server side socket, you get back a
> SocketChannel,
> and from there you can get to the socket. The process is reversed if
> given
> the socket, and it is non-blocking, then you can get access to the
> SocketChannel associated with the socket as you say.
>
> >
> > So a NonBlockingInputManager (input stage) is an implementation that
> > handles channel based non-blocking IO. Other implementations of the
> > InputManager can just handle blocking IO. We can have both residing
> > within the same server. For the time being SSL connections can
> > leverage the blocking IO stages rather than the NIO based ones until
> > SUN adds SSL support to the nio stuff.
> >
>
> Having both blocking and non-blocking io implementations is going to be
> difficult until we solve the issues with the SNACC stuff, which only
> supports
> blocking InputStreams.
That's ok it should not get in the way. Basically the non-blocking
reads trickle data into a decoders pipe. The read from the client
is non-blocking, the write to a decoding pipe is non-blocking but
the decoding read from the pipe can be blocking. So basically we
have a per-request object in the decoder that is managed until the
decoding reader completes reading an entire PDU.
Let me know if this makes sense. I might try to elaborate on this
after lunch. Also down the road we can rewrite snickers (SNACC
replacement that Rob wrote) so it uses non-blocking decoders and
encoders and is more SAX-like rather than storing the entire
image of the request PDU in memory but this is a long term effort
I think. Let me address this after lunch - my tape worm is not
letting me think.
>
> > So to summarize we need to determine if we keep the ClientKey
> > concept, how we manage protecting the socket when the code is
> > not trusted. Should we hide the socket or just carry it in a
> > event. Or is it best to have a service that enables access to
> > the socket based on the (old implementation) and we protect the
> > access to the service rather than the key.
>
> I don't see any reason any reason to protect the client socket. There are
> about a half dozen ways to get to it if you really want to, including
> hacking
> the code :-) By routing the Socket or SocketChannel through the process,
> you
> will avoid having to look it up later, and in my opinion keeps everything
> compact.
I don't know if I agree with this but let discuss it more.
>
> >
> >
> > 4). Interactions with server side JNDI provider
> > ===============================================
> >
>
> I agree this stuff is cool :-) Need to learn more about it.
Awesome we all need to get into this.
Alex
RE: Frontend redesign
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > See: http://somnifugi.sourceforge.net/
> Thanks for the link. A single VM JMS implementation
> is cool. I don't know if I am for or again the idea
> I'll have to think about it.
Same here. Just making sure that we have a common volcabularly for that
conversation. :-)
--- Noel
RE: Frontend redesign
Posted by Alex Karasulu <ao...@bellsouth.net>.
> > > It is best to use explicit listener interfaces to flag
> > > a stage as recieving certain events rather than exposing
> > > a generic stage enqueue() method.
>
> > Exactly! Take a lesson from the JMS folks and write a lean mean
> internal
> > message driven system. Would not a more appropriate term for this
> module
> > be QueueManager, rather than EventManager :-)
>
> See: http://somnifugi.sourceforge.net/
Thanks for the link. A single VM JMS implementation
is cool. I don't know if I am for or again the idea
I'll have to think about it.
Alex
RE: Frontend redesign
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > It is best to use explicit listener interfaces to flag
> > a stage as recieving certain events rather than exposing
> > a generic stage enqueue() method.
> Exactly! Take a lesson from the JMS folks and write a lean mean internal
> message driven system. Would not a more appropriate term for this module
> be QueueManager, rather than EventManager :-)
See: http://somnifugi.sourceforge.net/
--- Noel
Re: Frontend redesign
Posted by Wes McKean <wm...@logictrends.com>.
<snip>
> 1). Service Decoupling Using an EventManager
> ============================================
>
I really like the idea of decoupling the services by making everything event
driven. There are quite a few modules lying around that have circular
dependencies. By doing this, we basically have one dependancy, the
EventManager, and everything else is event driven.
<snip>
> However I think its best to hid this and not expose it as a
> service interface. It is best to use explicit listener interfaces
> to flag a stage as recieving certain events rather than exposing
> a generic stage enqueue() method.
Exactly! Take a lesson from the JMS folks and write a lean mean internal
message driven system. Would not a more appropriate term for this module be
QueueManager, rather than EventManager :-) Seems like we are going to be
creating and providing access to a number of queues, and modules can register
with each queue to listen for events. I assume that each queue would be
running in its own thread and distributing events to the appropriate
registered/concerned parties.
Question: If we are distributing events to registered listeners, is the Event
consumed after all listeners have been notified? I think so.
> 2). The SEDA stages, events and processing pathway
> ==================================================
>
> This is now really simple. A SEDA event is just like any other
> simple vanilla event. Except the difference is the nature of the
> sink makes the event handling semantics asynchronous yet the order
> of event processing is preserved by the stage's queue.
>
> The processing pathway was already covered above so there is not
> much that's left to be said here.
>
A SEDA event is just a different type of event...
>
> 3). Session handling, identity and synchronization
> ==================================================
>
<snip>
>
> Now keep in mind that for nonblocking IO the getChannel() call on
> a socket returns a non-null channel. For blocking IO or sockets
> created using methods other than through channel construction, the
> returned channel is null. So we can just give a stage that needs to
> work on a socket channel the socket. This means stages can detect
> the nature of events and determine if they will handle it or not.
When using a non-blocking server side socket, you get back a SocketChannel,
and from there you can get to the socket. The process is reversed if given
the socket, and it is non-blocking, then you can get access to the
SocketChannel associated with the socket as you say.
>
> So a NonBlockingInputManager (input stage) is an implementation that
> handles channel based non-blocking IO. Other implementations of the
> InputManager can just handle blocking IO. We can have both residing
> within the same server. For the time being SSL connections can
> leverage the blocking IO stages rather than the NIO based ones until
> SUN adds SSL support to the nio stuff.
>
Having both blocking and non-blocking io implementations is going to be
difficult until we solve the issues with the SNACC stuff, which only supports
blocking InputStreams.
> So to summarize we need to determine if we keep the ClientKey
> concept, how we manage protecting the socket when the code is
> not trusted. Should we hide the socket or just carry it in a
> event. Or is it best to have a service that enables access to
> the socket based on the (old implementation) and we protect the
> access to the service rather than the key.
I don't see any reason any reason to protect the client socket. There are
about a half dozen ways to get to it if you really want to, including hacking
the code :-) By routing the Socket or SocketChannel through the process, you
will avoid having to look it up later, and in my opinion keeps everything
compact.
>
>
> 4). Interactions with server side JNDI provider
> ===============================================
>
I agree this stuff is cool :-) Need to learn more about it.
Wes