directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [asn.1] Encoder interface
Date Sat, 24 Jan 2004 03:32:24 GMT
Wes,

Here's some background on some stuff in the past with LDAPd:

<background>

Ok a long while ago we came up with a SPI for ASN.1 message codec providers so you can plug
in SNACC or some other implementation so long as you wrote a provider.  That’s what the snacc-provider
directory under ldap is all about. 

Looking back at these interfaces I realize that I should have taken more time to carve them
out.  Not too nice but they seemed to work and reduced the dependence on SNACC and the ugliness
in the generated SNACC stub manipulation code.  The interfaces are two interfaces: one for
the encoder and another for the decoder.

The interface methods are as expected, a variant of the forms we’ve already seen in the encoder/decoder
stage service interfaces except they use streams which defeat the non-blocking features we
want.

    Object decode( Object a_lock, InputStream a_in )
        throws ProviderException ;

    byte [] encode( Object a_obj )
        throws ProviderException ;

</background>

We want to continue to maintain a SPI so implementations can be swapped in and out but we
need some changes.  

I think we need to revamp these interfaces to reflect the new NIO based approach and forget
about backwards SDK compatibility.  Furthermore at a minimum the decoder interface needs to
be replaced in total to reflect the chunk wise processing.

As a matter of fact I think it might even be better to break the encoded output into chunks
of smaller buffers and feed them to an output module.  Why you may ask?  Because large entries
with big blobs of binary data may exist where the returned buffer is huge.  We want to avoid
allocating too much at one time.  It’s much better to decode in chunks.  This way down the
road very large entry attributes or attributes referring to binary files can be streamed out
of the server in small chunks.  Basically we don’t want anything large to ever be held in
memory at one time.  So let’s add the extra requirement that we want to return one or more
chunks for output.

So which interfaces do you code to.  The SPI interfaces in the message codec
provider framework or to the Encoder/Decoder SEDA stage interfaces within the 
server?  I'd say neither.  We need new ones for all of it.

TBC in another email.

Alex


Mime
View raw message