Re: XDS based experience.......

[Andrew Waugh <[e-mail]>]

Panos,

> i am currently working in a project, which objectives are:
> 
> a) case studies describing a DUA or DUA API written on top 
>    of XDS being ported amongst several XDS implementations 
>    (currently ISODE & HP Open View).

I've not seen any work which tested the actual portability of XDS
applications. (Or, for that matter, the portability of applications
which used the related X.400 and X.700 APIs.) If anyone is aware of
any I'd like to know.

In practice, I'd expect some problems.

First, because there hasn't been any portability testing. The XDS/XOM
standards are complicated enough that individual implementors can make
subtly different interpretations of the text and hence produce
implementations that are not portable. The solution to this is a
'portability bakeoff' where various vendors implementations are tested.
A consensus of correct behaviour will quickly develop. The 'test'
applications then form valuable resource for testing correct behaviour.
This approach has worked well for the Internet, but I haven't heard
of it being adopted with XDS.

Second, because XDS is not a complete interface to X.500. In particular,
it doesn't provide access to the authentication features when binding,
nor has it been extended (as far as I know) to support the 1993
standard. Various implementations will have extended XDS in a variety
of ad hoc ways to support these aspects.

I will have practical experience of porting an XDS application within
a couple of months!

> b) developing a portable DUA or DUA API (using the XDS ISODE 
>    plattform), that can then been ported in a another
>    plattform (e.g HP Open View), just  by  compiling the own 
>    code and the ASN.1 definitios in the new plattform.
>          
> We are looking for the best way to develop something like this 
> above, without loosing the flexibility, which is provided, for example,
> currently by "libdsap.a" and "libdish.a" in the ISODE plattform. 
> Is there people having experience with APIs written on the top of
> XDS ?.      
> I'd be interested in any experiences poeple had.

I am not sure exactly what you want to do. XDS is designed to be
portable amongst many different systems and has been widely adopted
by vendors. If your goal is portability, you are unlikely to be able
to design an API which is more portable than XDS - simply because you
would have to convince the vendors to drop XDS and support your API.
So your goal cannot be (or shouldn't be) portability.

Is your goal to support the Quipu API on top of XDS? That would be a
useful goal. The major problems you will have (speaking from experience,
see below) is that it is very unlikely that the structure of the XDS
operation requests/results will map exactly into the Quipu equivalents.
They will *almost* directly map, but the exceptions will drive you
insane! (And mean a large number of exceptions to be
handled in code.)

My experience comes from working on a short project to provide a text
based interface to XDS. This constructs an XDS operation request from
a textual description of an X.500 operation. It also does the converse
for an X.500 result or error, allows the user to extract components
of the result by name, and supports cutting and pasting X.500
components.

The goal is to make it easier to use X.500, and to allow  more readable
(and hence maintainable) application code. The method is to produce a
toolkit which hides the details of using XDS (for example, memory
allocation, the structures used and how they are linked together, and
what the structure fields are for and how they are set).

andrew waugh