directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject RE: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring page is up
Date Fri, 21 Jan 2005 17:37:55 GMT
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,
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

	-----Original Message----- 
	From: Vincent Tence [] 
	Sent: Wed 1/19/2005 11:13 PM 
	To: Apache Directory Developers List 
	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:
	> 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