[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    Re: Dynamic syntax support
From:       Howard Chu <hyc () symas ! com>
Date:       2007-11-21 13:46:47
Message-ID: 474436C7.6000301 () symas ! com
[Download RAW message or body]

Howard Chu wrote:
> Here's a project for someone fairly ambitious:
> 
> The goal is to be able to dynamically add support for new syntaxes to slapd
> simply by feeding in their specifications. Typically this would mean feeding
> in an ABNF description from an IETF document, though it may also mean feeding
> in ASN.1 documents. E.g., we want to be able to insert (using ldapmodify) the
> ABNF into an LDAP entry somewhere and have it automatically converted into an
> executable parser.

> I think a more practical route will involve embedding a Forth engine into the
> OpenLDAP code. There's already been a fair amount of work done with BNF in
> Forth, so it shouldn't be too hard to get started:
> http://www.zetetics.com/bj/papers/bnfparse.htm
> http://www-personal.umich.edu/~williams/archive/forth/strings/index.html
> http://www-personal.umich.edu/~williams/archive/forth/strings/expr.html

> The nice thing about Forth is that the core language is tiny, it's extremely
> portable, it's extremely extensible, and any implementation is inherently both
> an interpreter and a compiler. As interpreted languages goes, it beats pretty
> much every other common scripting language for memory and CPU efficiency.

A parser that spits out Forth code would also make a good mechanism for the 
component-based matching functions. Even though we have dynamically loadable 
modules, relying on ASN.1 compilers like eSNACC is pretty clumsy. (And of 
course, according to the ITS, eSNACC is currently broken anyway.) This sort of 
thing ought to Just Work, without end-users needing any other development 
tools. I.e., LDAPadd an entry with ASN.1 structure definitions and immediately 
be able to perform component matching on the structures.

> It ought to be straightforward to convert a grammar into a set of Forth words
> to recognize the grammar, for a slapd syntax validator. I'm not sure yet what
> we would do for Prettifiers or Normalizers, nor what to do for Matching rules.
> We could simply accept them as Forth source code. Personally I haven't written
> Forth in over 20 years but it seems to me that a TIL is the most suitable type
> of language for the job.

> On the whole it doesn't seem like new syntaxes pop up in LDAP specs very
> often. Some may say this is because they're not really needed. I believe
> they've been sorely needed, and people have just avoided them because they
> required too much work to properly support in existing implementations. We can
> fix that.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/
[prev in list] [next in list] [prev in thread] [next in thread]