[Openslp-announce] OpenSLP moves forward once again
Brought to you by:
jcalcote
From: John C. <jca...@no...> - 2004-11-16 18:08:12
|
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. |