directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [asn1] Rewrite goals
Date Mon, 21 Feb 2005 20:38:37 GMT

It's very important that we have open discussions in general "on list" 
regarding our objectives with any effort.  We need to start summarizing 
stuff on IRC here on list so we don't have miscommunication or have 
repeat conversations.  This is critical for our success as a rapidly 
expanding community.  We saw how the TLV converstation was almost lost: 
what a waste that would have been.  I myself am the most guilty :(, and 
must appologize. 

So with that said let's come to an agreement WRT to our goals on this 
ASN1 rewrite.  Below are some of the goals I have in mind.  Let's add to 
them, remove some if need be, and embellish so we can set out on the 
right foot together.

NOTE: The fact that trade offs exist between these goals is implied 
rather than explicitly stated in some places.

1). We would like to make sure the implementation is easy to comprehend 
(requiring as little a learning curve as possible), is easy to maintain 
and hence extend.  More importantly we must lean towards making it 
easier for users than for implementors of codecs or stub compilers.

2). We would like the runtime to be fast and efficient.  We want to make 
sure the runtime more so than the compiler is most efficient both from 
the standpoint of time and space.  With the server, a fixed operational 
footprint for both encoders and decoders is critical.  Having the 
footprint vary as a function of the PDU size makes a server susceptable 
to DoS attacks.

3). Different protocols will have different encoding requirements or 
restrictions.  Furthermore different ASN.1 encodings will incur more 
costs since they have more rules.  There is no need to compromise 
performance for a generalized solution.  Using a combination of patterns 
we should be able to squeeze as much performance as possible without 
comprimizing ease of use while meeting the needs of different encodings: 
ultimately the needs of different protocols.  Separate implementations 
can be made plugable to reduce overheads while keeping the 
implementation extremely easy to comprehend, debug and maintain.  
Overall we want to have some semblence of a generalized or unified ASN.1 
runtime approach without paying for the penalties.  I think this will 
put the patterns we choose to use to the test.

4). With #3 its clear we want a unified interface for codecs even if 
implementations under the hood are made pluggable when the protocol and 
encoding is determined. 

5). We must also consider how the constructs in the runtime effect the 
stub compiler.  We want the prioritize a few things in the runtime over 
the compile time such as performance.  However we must draw a line where 
runtime constructs make it difficult or impossible for a stub compiler 
to generate code.  These trade offs I think will make themselves more 
apparent as we begin to investigate patterns and mechanisms for the 
runtime in conjunction with the build time.  This is not, at all, an 
easy thing to foresee.

Perhaps most importantly we need to make sure all ideas regarding ASN1 
are in the open.  I'm sounding like a broken record here, I know!  But I 
mean this in more than just a "put it on the list" sort of way.  For 
example, Alan has some great pattern useage in his branch and Emmanuel 
has great ideas he's putting forth in his wiki.  Let's begin tabula raza 
and make sure everyone is expressing their ideas yet again even if 
documented or within a code branch.  We can each delve into the work of 
others to look and learn but we should give some effort towards directly 
conveying the ideas we think are of value.  This will save time while 
investigating what others are doing. 

Do not presume others know what we have already discussed or what you 
(anyone) have cached within your head.  Take nothing for granted and 
presume people have not looked at your wiki, your online docs, or what's 
in your branch.

Let's start fresh, together!


View raw message