directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@iktek.com>
Subject Re: [asn1] why use TLV objects at all?
Date Thu, 24 Feb 2005 17:35:38 GMT
> >I also want to realize what is the cost of coding/decoding data against
> >the cost of fetching/storing them in the database. If it's a 50/50
> >ratio, we could have major performance improvement by first implementing
> >the layered approach then the compiler one when it's ready. If it's a
> >10/90, forget about layers. Let's focus on compiler on one side, and
> >other performance issues on the other.
> >
> >wdyt?
> >  
> >
> 
> This may be one of our "misunderstandings".  What is our goal? 

I pretty much feel it as a communication problem, as I'm quite a
newcommer on this project, so I missed a lot of explicit and implicit
informations. We have to write down all the implications of our choices
(our = community) in order to share the reasons we have made those
choices (be them good or bad). That takes time...


> IIUC, we already have a working version of ASN1 to get the ADS projects 
> up and running. 

not yet. I'm just focusing on the plumbing under LDAP messages, as it
was quite intricate in the current code, and as said on the WS :

"The internal 0.2 release was the first successful attempt to produce a
replacement for Snacc4J ... However the library does have performance
problems ... Furthermore the code base is very difficult to maintain
needing some reorganization. We hope to refactor the library so it is
more efficient, and easier to maintain while reducing the number of
dependencies it has. In the process we would like to introduce some new
features and improvements which are listed below ..."

I so I tried to brought my 2 cents there.


>  It is my goal to write a compiler that generates ASTs 
> which are translated into PO*Os and their family of encoders/decoders.  
> The ASTs allow us to target Java, C#, C++, etc.  The ASTs also allow us 
> to target new encodings when and if then come.  ASTs, I realize that 
> this is blue sky dreaming, allow for coding optimizations specific to 
> the protocol and target language, maybe even OS. 

Hem, I'm not so sure that AST could be helpfull to optimize anything, as
there is a 1 to 1 relation between the ASN.1 grammar of a protocol and
the ?ER to (en/de)code. I may be wrong...

Whatever, compiler are GOOD ! And having a compiler to generate ASN.1
codec is definitively a plus, especially if the underlaying coding is
PER.


> It's a big task and I welcome, no, *need*, any help that I can get.  To 
> that end, I hope that this goal is aligned with what the ADS community 
> needs.

It is aligned, as ASN.1 is widely used in LDAP, Kerberos, and many other
protocols we can have to deal with (even if RFC are not very respectfull
with ASN.1 syntax and semantic ;-)

But it can be extended to a point where it will become a standalone
project (the first free PER enabled compiler in the universe !)

> I am excited because it is clear that you have a thorough understanding 
> of ASN1 encodings and also seem to be well versant in compiler development.

I'm much more used to deal with compiler as it was one of my favorite
subject, and still is. ASN.1 is something that I'm following from the
distance, as I worked for Marben a decade ago. Funny that those
X400/X500/ASN.1 where buried a little bit to quickly ! (well, X400,
R.I.P) 


So, we absolutly have to work together (not only both of us) on these
subjects, and I'm a volunteer to help as much as I can ! 





Mime
View raw message