Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of aok123@bellsouth.net
 designates 205.152.59.69 as permitted sender)
From: Alex Karasulu <aok123@bellsouth.net>
Organization: Solarsis Group
To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
Subject: Re: RE: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring p
Date: Fri, 21 Jan 2005 14:50:10 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: 
 <20050121195010.YUMA2064.imf21aec.mail.bellsouth.net@mail.bellsouth.net>


> 
> From: "Tenc�, Vincent"
> 	 <vtence@optimuminformatique.com>
> Date: 2005/01/20 Thu PM 01:43:46 EST
> To: 'Apache Directory Developers List'
> 	 <directory-dev@incubator.apache.org>
> Subject: RE: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring p
> 	age is up
> 
> Keep in mind that my comprehension of the whole thing is limited at this
> time.
>

NP

> What I'm trying to understand is how the tuple interfaces are going to be
> used. If I'm not mistaken,
> the BERDecoder/BEREncoder is manipulating tuples. How do you envision that
> those interfaces will be used?

Take a look for the moment at how we already use them with generic interfaces on the asn1 site:

http://incubator.apache.org/directory/subprojects/asn1/codec-stateful/index.html

Now just presume some changes to these interfaces to make them less generic and more specific to ASN.1 without exposing implementation details.  This is how the encoder decoder will operate.  Encode decode operations regardless of the nature of the codec will be standardized by the interfaces chosen.

Now what may be different is how to setup different codecs.  For example one that can serialize large values might take a configuration parameter for the threshold at which it begins streaming to disk.  Regardless of these differences in setup the top level exposed API should be the same regardless of the codec impl used.
 
Does that help?

> It looks like decoders/encoders will need to know the specific type of the
> tuples they're working on 
> to use them properly.
> 

Right the codec implementer will need to be aware of this but the codec user does not.  This is what we want.  Implementors bear the grunt of having to know the differentiations on Tuple.  IMO that's well worth it when users are keep free of knowing these details.


> More reply inline.
> 
> > -----Original Message-----
> > From: Alex Karasulu [mailto:aok123@bellsouth.net]
> > Sent: January 19, 2005 11:30 PM
> > To: Apache Directory Developers List
> > Subject: Re: [asn.1] sitedocs update for 0.3 dev cycle - new 
> > refactoring
> > page is up
> > 
> > 
> > Vincent Tence wrote:
> > 
> > > I've been looking into this recently. While I still have a lot of 
> > > things to figure out to understand the whole thing, a few 
> > question are 
> > > popping in my head regarding the refactoring, specifically the ber 
> > > subproject.
> > >
> > > If I'm getting this right, the base idea is to replace an 
> > all-in-one 
> > > tuple class with an inheritance hierarchy. While I'm all to 
> > the idea 
> > > of factoring behaviorial differences into specialized 
> > subclasses, I'm 
> > > not getting how client code is supposed to deal with the 
> > specialized 
> > > tuple classes. 
> > 
> > Ahh ok client code does not deal with Tuples.  This is still 
> > an internal 
> > class.  We're only talking decoding at this time so don't worry about 
> > encoding aspects.  The tuple is an internal detail of a decoder.
> 
> Sorry by client code I meant code using the Tuple class, i.e. Decoder.

Ahh ok codec implementors will need to know this stuff but that's fine by me so long as end users of a codec are insulated.

> 
> > 
> > > Since they all expose different interfaces, how are codecs 
> > supposed to 
> > > manipulate them? I would have thought we wanted to hide their 
> > > differences in behaviour as an implementation detail rather than 
> > > expose them. This way codecs could manipulate the all the 
> > tupples the 
> > > same way.
> > >
> > I agree with you totally.  Tuple is not to be an exposed 
> > class.  Sorry 
> > your confusion is my fault.
> > 
> > > I tend to favor a Tell, Don't Ask style of programming, so 
> > I'm always 
> > > suspicious about getters and classes that are willing to 
> > disclose too 
> > > much of their internal affairs ;-) Rather than have generic 
> > interfaces 
> > > for decoders/encoders and tuples that expose their implementation 
> > > details, 
> > 
> > Is this what is being done?
> 
> The Encoder and Decoder interfaces look very generic. On the other hand, the
> Tuple interfaces
> are much richier and provide a lot of details.
> 
> > > what if we could factored out the operations we want to do with the 
> > > tuples into TLV specialized encoders/decoders interfaces?
> > 
> > So don't specialize the Tuple just the higher level exposed API?
> 
> I'm having trouble getting understood again ;-) Still trying to figure
> out what operations we want to do on tuples. I can see we can get some
> values out of the tuple using getters:
> 
> isConstructed(), isLengthDefinate(), ... 
> 
> but I'm not sure how this information will be used yet. I'd like to look
> at the why we want this information to see if we can come up with a useful
> abstraction that helps us manipulate all tuples the same way. 

Codecs at the lowest level must switch lexically to capture and process different kinds of Tuples.  These methods help them query what tuple is being processed and change lexical state.  It also makes the code cleaner when we're not dealing with just low level byte access to make these decisions.  Hence these methods...

> > 
> > > That would leave us with a much simplier TLV abstraction that our 
> > > codecs can manipulate the same way without knowing about 
> > constructed 
> > > vs primitive vs streamed tuples.
> > 
> > Can you elaborate some more on this?  How can we do this - do 
> > you have 
> > an example that could make seeing the picture easier?
> 
> My reasoning is that we'll have a lot of different tuples to encode/decode
> with
> a single decoder at a time. So I wouldn't care much if my coder (meaning
> either 
> decoder or encoder) interface is designed towards coding tuples only if it
> lets me
> deal with all sorts of tuples in a simple and single way.
> 
> I'm afraid my understanding is still too limited to come up with a useful
> example.
>  

no problem you're doing great keep asking the questions...

Alex

> > >
> > > Is that making any sense at all or should I go back study 
> > the code and 
> > > read that refactoring page once again ? :)
> > >
> > No no I'm trying to understand your suggestion but my brain is a bit 
> > fried right now.  
> > 
> > Also on a separate note.  Perhaps I've done the wrong thing here in 
> > trying to get others interested in asn1 by refactoring it.  A massive 
> > restructuring may not have been the best route to go.  Perhaps we can 
> > see if you can first massage out the Snacc4J deps instead.  I'm 
> > realizing my approach to cross reactivity might have been flawed :(.
> > 
> > This is separate from trying to understand your comments though.  I 
> > would love to have more of your input.
> > 
> > >
> > >
> > > Alex Karasulu wrote:
> > >
> > >> Hi,
> > >>
> > >> I updated the asn1 sitedocs because I added a new document 
> > describing 
> > >> some of the changes we intend to make to that module.  
> > These are for 
> > >> clarity of code and performance reasons.  Also to protect better 
> > >> against DoS attacks in the future.
> > >>
> > >> The main page for the module is up here:
> > >>
> > >> http://incubator.apache.org/directory/subprojects/asn1/index.html
> > >>
> > >> The refactoring informationg going into 0.3 over time is 
> > described here:
> > >>
> > >> 
> > http://incubator.apache.org/directory/subprojects/asn1/refactor.html
> > >>
> > >> Happy reading for those interested.  Also I'd like to see 
> > if people 
> > >> are interested in helping out to make these changes happen before 
> > >> groking all this myself.  This is why I documented most of 
> > this.  I 
> > >> would like to start taking a step back to let others have 
> > a chance do 
> > >> more on these projects.  This will help promote better cross 
> > >> reactivity between our committership :).
> > >>
> > >> Anyone interested?
> > >>
> > >> Cheers,
> > >> Alex
> > >>
> > >>
> > >
> > >
> > 
>