🚀 go-pugleaf

unikjtf@uts.uni-c.dk (Jan Ferre') writes:

>I'm missing OSI in real life!

So do I!

>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.

Using C structs as the API specification might not be a good idea under DOS.
Different compilers might produce different memory layouts and it should not
be necessary to use the same compiler for the TSR driver and the application.

>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.

Under MS-DOS an machine-level API and a standard C++ interface for the higher
cut might motivate a lot of PD programmers to implement interesting
applications without having to worry about the details of layer 4-6.5.

>Now whats wrong with the standards themselves? Simply that they don't 
>provide the information needed to ship binary modules that the users can mix.

>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.

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!

If enough people come together, I might find some time to implement
a below-network API TSR module for async HDLC and X.25. The prototype is 
already available, I still don't have a nice API and I don't want to 
construct my own API.

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----