DMCL: Language-Neutral API

One thing that first impressed me about Documentum was its language-neutral API. You could add the full Documentum API to any programming language by adding a few C functions and the DMCL. Unfortunately EMC no longer sees this as a strength and is trying to replace it with a pure language-specific (Java) solution.

First, thanks to ukdavo for his comments on my post about Aspects in D6 and Ruby on Rails. Both comments added interesting new technology to my list of things to investigate, like Groovy and Grails. Java without the bitters and jitters perhaps? Groovy wins quick points with me by having a python-like interactive mode; scripters and Agile fanatics living in a Java world might want to check it out. He calls on EMC to support using the Documentum APIs from more places and retire DocBasic. I completely agree and hope that EMC will consider returning to one of the basics that made Documentum great for developers.

The Documentum Client Library (DMCL) is the core C/C++ code that unifies a docbase’s underlying components into a single cohesive layer. There are also some proprietary crypto libraries in later versions, something I banged up against when compiling the first Linux version of dmperl at M. It also included a custom version of libC.a on Solaris that made using Sun’s professional C++ compiler difficult: That’s why my first major Documentum project was done in C rather than C++. I never did find out what they hacked in libC.a. Anybody know? Please post a comment.

The DMCL gets distributed as DLLs or shared objects depending on the platform. It’s a huge and complicated hairball of code with more rings than a hundred-year-old Redwood tree, but Documentum came up with an incredibly simple five-function interface for anything wanting to include the libraries. Two of those functions were basically housekeeping: dmAPIInit() and dmAPIDeinit() did things like allocating memory for the sessions, caching, and garbage collection. Even relative newbies to Documentum have seen the three workhorses via DocBasic: dmAPIGet(), dmAPIExec(), and dmAPISet(). That’s it. Five functions gives you access to the entire DMCL.

The workhorse functions take a string argument that’s basically a message to a DMCL session. Here’s where brilliance missed a step by trying to be helpful: Instead of the more proper message format of “<session>,<method>,<arguments>”, Documentum decided on “<method>,<session>,<arguments>”. It seems like such a small thing, but it’s always a a bother choosing between consistency with the API or doing the right thing in the inevitable wrappers people write around them. I’ve written a dozen versions for a half-dozen languages and never completely resolved the argument. At least I got to take J. to task for this “helpful idea” when he was doing the Alfresco dog-and-pony show for M. If I could go back in time, I’d have rewritten those three functions to take separate string arguments for session, method, and arguments. Ah well.

Documentum provides a version of gawk with the DMCL included, and I’ve evangelized dmperl for over ten years now. It was incredibly easy to dm-ify any programming language, especially an open source project. That meant you could choose the right tool for the job. I loved dmperl because most DMCL work is string handling: building method strings and parsing results. Nobody does strings better than perl. I bet some Emacs fanatic even compiled in the DMCL or made a dmLisp. For the record, that counts as unleashing an unspeakable evil on the world.

Next time we’ll take a look at Documentum’s move to a language-specific implementation and how it differs from the original approach.