Converting 'an' API to run against QUIPU

[Bobby Martyna <[e-mail]>]

  christian, you wrote

> I presume that RETIX, like most players in this field, is using a programming
> environment capable of handling ASN.1, ACSE, ROS and of generating
> automatically from an ASN.1 protocol spec what I called "stubs"...

  this is true for all products, in particular, non-standard api based
  products.  however, where a standard api has been defined, the situation
  is -much- simpler from the application development viewpoint.  in short,
  the burden of creating these stubs is alleviated, along with the non-
  standard means of specifying the input to the stub compilers...

> In this case, I maintain that simply taking the ASN.1 spec of XDS and running
> it through your own ASN.1 compiler, and linking it with your own "OSI Run
> Time", provides you as much portability as the X-OPEN API. You would in any
> case need the ASN.1 compiler for the application itself, and the proper way
> to solve "system dependencies" is probably the transport layer interface --
> using e.g. the X-OPEN TLI. Using the same ASN.1 spec, specified by an
> international standard, guaranties interoperability between the DUA that your
> compiler generates and whatever tools were used to implement the DSA.

  no.  the api-based products include everything from the api down to the
  x-open tli and/or xap and you do -not- need an asn.1 compiler.  this is
  because the x-open xom structures have been more or less canonically
  defined to map to the asn.1 constructs.  an application writer fills in
  these structures and the xds service takes care of the parsing and
  formatting into ber.

> To put it shortly: you need an ASN.1 compiler to develop an OSI application;
> once you have chosen the compiler, it will provide its own APIs for all
> services whose interfaces are specified in ASN.1. The advantages of doing so
> are indeed the integration of data structures, the possibility to use
> compiler optimizations, and the possibility to adapt to different programming
> languages, e.g. LISP or ADA as well as C. 

  as i mentioned, no asn.1 compiler is needed where a standard api has been
  defined.  as far as optimization, the implementation translates directly
  between the structural representation of xom objects and the encoded
  data stream.  if you'd like more details about this, you can e-mail me,
  but the point i want to make in this mailing list is, no asn.1 compiler is
  needed, allowing application developers to simply link with an api library,
  either statically or dynamically.  this makes for a much more attractive
  and portable application development environment.

  bobby