[eve] RE: Frontend redesign

[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