directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tencé, Vincent" <>
Subject RE: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring p age is up
Date Thu, 20 Jan 2005 18:43:46 GMT
Keep in mind that my comprehension of the whole thing is limited at this

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?
It looks like decoders/encoders will need to know the specific type of the
tuples they're working on 
to use them properly.

More reply inline.

> -----Original Message-----
> From: Alex Karasulu []
> 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.

> > 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. 

> > 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
a single decoder at a time. So I wouldn't care much if my coder (meaning
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
> >
> > 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:
> >>
> >>
> >>
> >> The refactoring informationg going into 0.3 over time is 
> described here:
> >>
> >> 
> >>
> >> 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
> >>
> >>
> >
> >

View raw message