🚀 go-pugleaf

In article <1gqaiuEINNhdo@uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de writes:
>unikjtf@uts.uni-c.dk (Jan Ferre') writes:
>
>>Now here's my proposal: Why not define a set of interfaces for specific 
>>computerseries and especially for specific operating systems in order to 
>>ease PD programmers to get started. I suggest something like:
>>   Interface to TP is done via device OSITP on DOS.
>>   Packets to the interface are submitted as struct { bla bla bla } and the 
>>   results will be returned as struct {blu blu blu}.
>
>Excellent idea! Why don't you start writing a proposal, post it here,
>then we'll discuss it and then we'll see whether anyone wants to
>write a demo implementation.

What is the difference between what you're planning to propose and what AT&T's
TLI (Transport Library Interface) does for you at Transport Layer? In fact,
X/Open have their XTI (X/Open Transport Interface) standard and their XAP
(X/Open Application/Presentation) interface standard, which is the equivalent
of AT&Ts APLI (Application/Presentation Library Interface), etc. There are
alos X/Open draft standards for local syntaxes etc (e.g. XOM).

>>It should be possible to identify several 'cuts' in the 7 layer model - in 
>>fact a cut is needed at least for every possible split possibility: In the 
>>Nordic Government OSI Profile there should be a cut to provide for 8802-3 
>>and -5, a cut to provide for 8878 as contrast to 8473, a cut for 8073, and a 
>>cut in 8650 to provide interface for the different layer 7 applications.
>
>I would suggest only 2 cuts: one cut near the network layer and
>one cut that offers ACSE, RTSE and ROSE to the higher layers together
>with BER/PER/... parsing service (that's what application programmers need if
>they want to implement a FTAM client prototype within a few days.)
>The cut within the network layer need not necessarily be one of the
>cuts in the OSI RM. The module below the near-network-cut should
>contain the network specific software (e.g. an async HDLC/X.25 driver
>for COM1 and COM2, an CLNP driver over a packer driver, a 'for further
>study' CONS module using AX.25, etc.). The module between the two cuts
>would perform all the OSI protocol machinery (from transport to ROSE)
>in which both the network and the application programmer aren't very 
>interessted.

You are confusing 'cuts' with interfaces, surely? Interfaces should be defined
at the Transport Layer (since this is the basic Transport service), and then
probably above ACSE/Presentation, to provide a basic Application service,
suitable for any Application Process.

Combinations of protocols are generally referred to as 'profiles'. This is a
different issue.

>>My dream (let's call it a wish for christmas) is to go to SIMTEL to get 
>>layer 1,3,5, to buy layer 2 and 7 from IBM and to buy layer 6 and 4 from 
>>Nonsence-soft in Yougoslavia. Or at least to be able to get hold of 
>>resonable modules from different sources.

You can do that now with the lower 4 layers! Most Transport products for
workstations (e.g HP, Sun, etc.) will conform to a standard TLI (either
AT&T or X/Open - these are virtually identical anyway).

>Perhaps a seperate module for each OSI RM layer isn't even necessary.
>Developing nice APIs is a lot of work, so let's concentrate on a few only!

Agreed! Let's use the ones that are available!

Ian.

-- 
-----------------------------------------------------------------------------
Ian Newman, BNR Europe Ltd.,		 	 | iann@bnr.co.uk
Transmission Software Development (Dept. GM21),	 | Phone : +44 (0)81 945 3638
Oakleigh Road South, London N11 1HB, UK. 	 | Fax   : +44 (0)81 945 3116