🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.iso
Article #912

XOM and XDS - more info

#912
From: Brian May
Date: Tue, 13 Oct 1992 02:09
76 lines
3138 bytes
A couple of people have expressed interest in further explanation.  Most of
those are lucky enough to have the task of implementing (at least) XOM for
support of other X/Open APIs.

-----

First of all, a little about XOM - as all X/Open OSI Application APIs require
it.

The specification/definition for XOM is text based with C like definitions
of the functions.  The descriptions of those functions are fairly sparse and
leave a fair amount open to interpretation.  A very brief description 
follows.

Comments/corrections welcome.

XOM
---

XOM manages 'OSI' or 'ASN.1' data objects for an application API.  XOM has
2 different concepts of these objects which it calls PUBLIC and PRIVATE.

Public & Private objects
------------------------
PUBLIC objects are those which the client can modify the contents of.  
PUBLIC objects are basically arrays of descriptors (which hold type, syntax
and value of attributes).  This obviously makes insertion/deletion/allocation
of attributes within the object a pain!

A PRIVATE object's structure is implementation dependent.  Only the header
to an object must have a common structure.  The attribute descriptors can
be implemented any way you wish (eg doubly linked list).

Clients of this API can only use PUBLIC objects and have to create a PRIVATE
object, and subsequently take a PUBLIC copy for use.

EG.  When a DUA wishes to create a bind argument, it must first directly
use XOM to create the object, take a public copy of the object, then use
the XOM encode function before it can send the bind request via XDS and
the protocol stack.

OIDs and Class Tables
---------------------

XOM holds a _static_ class table containing all the OIDs it knows about.
If you want to dynamically use/create a new object, it'll have to be 
re-compiled into XOM's class tables.

Class table structure is left up to the implementor.

Encode/Decode
-------------

These merely create the relevant structures for sending/receiving ASN.1
data relevant to the protocol stack in use.  (We use PEPSY for ISODE)

Diagrams
--------

I have a couple of MacDraw diagrams available which show the relationship
between a DUA, XDS, XOM and a protocol stack (ISODE).  They are available
via anonymous ftp from:

mel.dit.csiro.au	 in the directory 	staff/brian/API

I'll put TIFF and PostScript versions there also.


---------------

brian
--
| Brian.May@mel.dit.csiro.au |           Open Systems Program           |
| CSIRO/DIT, 723 Swanston st | TEL +61 3 282 2613 -- FAX +61 3 282 2600 |
|Carlton, VIC 3053, Australia|          Experimental Scientist          |
Technical Details
Message-ID: <1992Oct13.020901.3410@mel.dit.csiro.au>
Path: arc1-ca.pugleaf.net!sparky!uunet!charon.amdahl.com!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!eff!news.byu.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!usc!rpi!batcomputer!munnari.oz.au!mel.dit.csiro.au!brian

Show Full Headers
Complete Article Headers
Newsgroups: comp.protocols.iso
Path: arc1-ca.pugleaf.net!sparky!uunet!charon.amdahl.com!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!eff!news.byu.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!usc!rpi!batcomputer!munnari.oz.au!mel.dit.csiro.au!brian
From: brian@mel.dit.csiro.au (Brian May)
Subject: XOM and XDS - more info
Message-ID: <1992Oct13.020901.3410@mel.dit.csiro.au>
Sender: news@mel.dit.csiro.au
Organization: CSIRO DIT (Melb.)
Date: Tue, 13 Oct 92 02:09:01 GMT
Lines: 76