[Openslp-announce] OpenSLP moves forward once again

[John C. <jca...@no...>]

Everyone,
 
I apologize for the lack of traffic on this list. I know it's been sort
of quiet lately. I've recently taken ownership of this project. I wanted
to make a public statement concerning the future direction of the
OpenSLP project. I've spent the last couple of weeks familiarizing
myself with the current implementation, and I now feel more comfortable
making an agenda for completion of partially implemented or missing
features, and for performance enhancement.
 
The following features are missing, or could be optimized:
 
1. Asynchronous UA operation. This is currently only partially
implemented. Mainly what's missing is threading primitives, and the
correct management of client library threads. It's really fairly trivial
at this point, but was never added for a couple of reasons that I can
determine. First, the entire code base is currently single-threaded
(even slpd). There's nothing wrong with this. A good single-threaded
implementation can be faster than a multi-threaded implementation, if
done correctly. Threading adds SMP scalability, not speed. I would like
to add threading to the UA for asynchronous API operation.
 
2. Which brings me to my next point - SMP scalablity for slpd. I don't
want to add lots of threads to the server. Even in large installations,
the traffic just doesn't warrant adding threading on a massive scale.
However, I do believe performance would be benefited by multi-threading
the server, specifically for DA's, which do receive more requests than
SA's. Adding threading in both the UA and the SA/DA server requires the
creation of a small set of threading and synchronization primitives,
including threads, mutexs and condition variables, at the very least. I
need to consider options that are already available, of course, but one
concern is that up to this point, the OpenSLP source base has been
entirely self-contained. Maintaining this self-containment has to be
considered in any decision regarding which threading library to use.
 
3. Remote database configuration. I'd like to add _configurable_ LDAP
support to the DA. That is, I'd like the storage of directory
information to be configured to be internal or external via OpenLDAP
based on administrator policy. Directories are somewhat commodity these
days, and nearly every installation site for OpenSLP also has a
corporate directory available. Another configurable storage option might
be an ODBC or other standard database interface for storing directory
information in a more optimal format. These features would lend
themselves to persistent service registry, as well, which was never
fully completed.
 
4. It's time for a refactor. There are many places in the code base
where it's pretty clear that code was just copied wholesale from one
routine to another, because it was convenient and fast. Refactoring
means moving code into common routines, to improve maintainability, and
reduce defects.
 
5. After a while, the source code of an open source project with
multiple developers tends to take on a "wild-hair" sort of look. That
is, the formatting from one source file to another is disjoint and of
different styles. While the OpenSLP project is not too bad in this
respect, given the amount of time it has been alive, it could use a
little reformatting to get it back to a smooth source base. To this end,
I've purchased a license for a share-ware product called
SourceFormatterX, which is really cool. I'll be setting it up to restyle
the code base to match most of the style that Matt Peterson used in the
original source code a few years ago. These changes will affect many
source files at once, and I expect to do this major formatting change
soon.
 
I'll be sending out more notes like this occasionally to announce other
areas on which I intend to spend time.
 
Thanks for your support. Please feel free to let me know of features
you'd like to see. I'm monitoring these lists, and I want the traffic
logged and publically visible, so it's probably most appropriate to use
the openslp project's developer mailing list at
ope...@li..., however you are welcome to email me
directly, as well at jca...@no.... 
 
John Calcote
Novell, Inc.