When you speak of factoring behaviorial differences into specialized subclasses, do you mean
factoring the factoring behaviorial differences of the *general* encoders, e.g. BER, CER,
DER?
I also am in agreement that the Tuple code should be replaced. It makes way too many objects
and iirc uses a production rule style for decoding, which can be pretty slow. The tack that
I've taken, and am working on in the ASN1 branch, is to compile the ASN1 module into specialized
encoders/decoders that are specific to that ASN1 module. There could be a version for BER,
DER, etc. The speed increase of this is pretty good, my simple SPNEGO BER example takes an
order magnitude less time than what Snacc4J does.
I'd welcome any help that is offered but, it seems like you're having a fun time exploring
your ideas. Feel free to contact me with any ASN1 questions; I can be found on the directory-dev
IRC.
Regards,
Alan
-----Original Message-----
From: Vincent Tence [mailto:vtence@videotron.ca]
Sent: Wed 1/19/2005 11:13 PM
To: Apache Directory Developers List
Cc:
Subject: Re: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring page is up
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
>
>
|