Up until now I've kept my mouth shut (at least on this here blog) on the subject of Undocumented Interfaces, a.k.a Unsupported / Legacy APIs. I've been resisting for some time, as to be blunt, whilst important - this is a very tedious issue.

Stefan has recently posted a series of excellent entries on this topic. Stefan calls these things 'undocumented interfaces', but seeing as I don't work for Microsoft, I'll be calling them 'legacy components'. :)

There are some key points about this whole thing which are very annoying...

1. It's groundhog day (again).
Back when 2001 shipped (or was rebranded depending upon which way you look at it) the newly created cmserver newsgroup often featured threads about touching the database. Now I hear you say - "but this isn't about the DB, it's about the APIs" - which is true - but essentially it's the same core principle. I remember also have a somewhat heated discussion with one of my developers at the time that it wasn't appropriate to be fiddling with the legacy components in a VB6 project - which a number of folk, including MCS had done some stuff in - i.e using the non HTTP context style access.

Shortly after the 2002 release the topic once again came up - both touching the DB and using legacy components (AEServer etc).

Seemingly every six months or so this issue crops up as someone new to the product finds out they can't do some things they'd like to with PAPI. Also, I've had at least six occassions over the past couple of years where I've have to give a slapdown to devs hooking up to the legacy components or doing silly things with the database.


2. The idea in principle is daft.
So you pay a stack of cash for an ECM - the whole model of which is to abstract the system through an API. Despite the naysayers MCMS is an ECM, but has some major elements missing from the PAPI. Do Obtree C4 developers have the same problem, do Interwoven developers have the same problem? Of course they do. No surprises there really. Feedback to the vendor gets it fixed.

Seemingly it's a codehead problem, especially in partner type companies - developing solutions using the legacy components is interesting from an academic and or hack and slash perspective - but delivering them to a customer (whom are the people who have purchased those stonkingly expensive CPU licences and then immediately violating said licences) is another matter.

3. It's not about the code, it's about the solution
MCMS isn't the only product to have this 'issue' - SharePoint technologies have the same things - don't touch the DB - parts of the API suck - some of the Web Services suck - some stuff you can only do at a command line etc. So does Reporting Services - the Report Manager - nice but not quite what you might want. The list goes on and on. Did anybody mention Site Server?

But here's the rub.... take the "missing" user management 'in' the PAPI - folks writing code to the legacy components are writing code against the legacy of Resolution (yes) which in turn relies on AEServer service etc ... for security!!!! Get real!!! In addition, it doesn't take much exposure to Windows Security to get that this nasty auth proxy will be gone gone gone (and good riddance to bad rubbish).

The second part of this is say you develop some elements outwith the rules - how does that effect deployment, operations, DR etc etc. For example, in SPS you can easily destroy your ability to move portals about if you've done some non compliant hacks. Of course there is also the service pack and/or hotfixes to worry about also.

The Bottom Line:
Follow the rules and look for a real solution to the "missing" functionality rather than some hack.


Unfortunately for readers - I will continue this rant in part two...