[asn.1] sitedocs update for 0.3 dev cycle - new refactoring page is up

[Alex Karasulu <ao...@bellsouth.net>]

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

Re: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring page is up

[Alex Karasulu <ao...@bellsouth.net>]

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

Re: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring page is up

[Vincent Tence <vt...@videotron.ca>]

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. 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 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, what if we could factored out the operations we want to do with 
the tuples into TLV specialized encoders/decoders interfaces? 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.

Is that making any sense at all or should I go back study the code and 
read that refactoring page once again ? :)

- Vincent





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

Re: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring page is up

[Trustin Lee <tr...@gmail.com>]

Hi,

On Sat, 15 Jan 2005 16:00:08 -0500, Alex Karasulu <ao...@bellsouth.net> 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
> 
> 

Looks interesting.  Before looking at the code deeply, I need to learn
about ASN.1 encoding. :)

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/