The octet bridge does not try to understand the messages flowing back and forth between the client and server but looks out for bursts of traffic. These bursts are then logged using the OpenSkills logging library. Here is an example of a captured burst between the ldapsearch LDAP client and the OpenLDAP server:
<t>Thu, 31 Jan 2008 05:52:38 GMT</t>
This sample can then be added to SUnit tests for the Slaps parser. Once we have captured the messages for an exchange we are interested in, perhaps a client logging into a PostgreSQL database and PostgreSQL then issuing an LDAP request to see if that client can indeed login, we can set up the SUnit tests and make sure the Slaps parser can handle the various messages in the flow.
Now we can use the parsing bridge instead of the octet bridge. Instead of looking out for bursts, the parsing bridge relies on the Slaps parser to know when a complete message has been received. The parsed message is then re-encoded by the Slaps library and sent on it's way. Once we have the entire exchange passing to and frow through the parsing bridge without any problems we know we can reasonably handle the messages in this kind of request.
The last step is to use the Slaps library to respond to the LDAP messages directly. For example, in the case of OpenSkills we want to manage access our internal Store repository. With Slaps we can refer to the objects that make up the membership system to answer an LDAP authentication request from a PostgreSQL server.
Using bridges and SUnit testing to build up support for a protocol is not limited to LDAP and Slaps, and could be used for any streaming protocol. These techniques are not new, of course, but it is nice to have this all working smoothly in my Smalltalk development environment. It certainly makes working on Slaps much easier.