directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <akaras...@locus.apache.org>
Subject Re: Re: [asn1] Stateful Decoder question.
Date Wed, 05 Jan 2005 22:23:59 GMT

> 
> From: Richard Wallace <rwallace@thewallacepack.net>
> Date: 2005/01/05 Wed PM 02:48:44 EST
> To: Apache Directory Developers List <directory-dev@incubator.apache.org>
> Subject: Re: [asn1] Stateful Decoder question.
> 
> akarasulu@locus.apache.org wrote:
> > Rich,
> > 
> > I looks like you have really started digging into the Stateful codec stuff in asn.1.
 What do you think about it regarding your use cases?  What ways do you think it can be improved
or would another model work better?  Just looking for more feedback.
> > 
> 
> Heh.  Don't give me too much credit.  I've only looked on the surface at 
> the StatefulDecoder interface and how it's used in Eve.  The only 
> limitation I've run into is that there is no way to share state between 
> the decoder and the request handler.  

Hmmm I'm wondering how this might be achieved.  Perhaps the 
decoder can take share some session object but that may be moot
when Trustin and Berin come up with their interfaces which might 
account for this.

It's very important that we keep asking for them to support your 
use cases.  I suspect mail will not be the only protocol this will 
be needed for.

This is something that I've 
> mentioned before, so I won't go into too great a detail.  

Yeah I guess you mentioned it here:

http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=directory-dev@incubator.apache.org&msgNo=3150

And btw you are never "rambling" as you said in the email.  Your comments and 
experiences are valuable to us as we carve out these APIs.  These are contributions
on par with patches if you ask me.

Basically, 
> depending on the state of the connection the decoder might be expecting 
> the client to send certain things (commands vs. data for instance) and 
> do different things with what it gets (parses it or just passes it 
> along).  

So in general you would like to have the handler manage the "lexical state" so to 
speak of your decoder.  And it does make sense to keep some of the state management
within the handler if the request is a multi-part request if I'm understanding you 
correctly.

The problem arises that if there is an error in the request 
> handler and the state should be changed, there is no way to notify the 
> decoder of this change in state because there is currently no way of 
> getting at the session in which the decoder is being used.  The protocol 
> api doesn't have this limitation because the ProtocolProvider gets the 
> client socket when the getDecoder() method is called so you can easily 
> associate sessions with decoders and vice-versa.
> 
> > I'm asking because I myself and with others often criticize the callback approach.
 Sometimes it gets confusing and is not that easy for people to understand.  
> > 
> 
> It does seem confusing at first, I guess, but I kinda like it.  It's a 
> simple way of communicating to the caller that something has happened 
> and it needs to do something.  Another way to do it would be to have the 
> caller and the callee share a queue and when the callee needs to send a 
> message to the caller it enqueues it.  Then, the caller can either 

I would really like to see what Trustin and Berin think about this as well or if
they have other approaches they can recommend.  

> listen for updates to the queue via the publisher/subscriber pattern or 
> it can poll the queue periodically.  I don't know which solution is 
> better, I think they both have their own merits and drawbacks just like 
> anything else does.

Cool thanks for you're comments, and keep em coming.  Community is very
important to us. 

Alex




Mime
View raw message