directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring page is up
Date Thu, 20 Jan 2005 04:30:05 GMT
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.

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

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

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

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


Mime
View raw message