papa@pollux.usc.edu (Marco Papa) (07/01/89)
I've just sent to Bob Page, the moderator of comp.sources.amiga, the sources
for XPR, the "External File Transfer Protocols as Amiga Libraries Standard" for
allowing communication programs to 'share' protocols between each other and
provide end-users a way to write their own protocols. XPR has been designed by
Willy Langeveld of SLAC, the author of VLT. Since we at Felsina Software
were planning to implement a similar scheme, we decided to adopt Willy's
standard and provide input in its design. The current design has undergone
a number of revisions and is also open to subsequent expansions if needed.
Of course VLT includes support for the XPR standard. Felsina Software has
announced that it will include an implementation of XPR in an upcoming version
of A-Talk III. An announcement will be made when such support will be
available. In fact we will provide support for CIS B Plus as an XPR library
in our first XPR-based release. This version of course would work with VLT
and with any other comm program, commercial, pd or shareware that decides to
support XPR. We encourage any of these developers to join the XPR standard.
Standards are good for everybody, users as well as developers.
To give you an idea of the implementation, let me briefly quote from Willy's
Introduction from the XPR documentation:
-- beginning of quote
XPR: External File Transfer Protocols as Amiga Libraries.
=========================================================
Version - 29 June 1989
(C) Copyright 1989 by
W.G.J. Langeveld
Stanford Linear Accelerator Center
One of the most frequently asked questions of the author of a
communications program is "Why don't you implement this wonderful file transfer
protocol in addition to the 25 you already have?". Clearly, implementing more
FTP's leads to larger code size and to increased product development time and
customer support requirements, unless there is a way to have the additional
protocols available as separate entities. One obvious way is to put the
additional FTP's in overlays, but that only mitigates the code size problem and
does not allow protocols to be used with communications programs of different
vendors. Better is to open the serial device as a shared port and to have a
completely separate program access it at the same time. However, this method has
the disadvantage that shared use of a single serial port can lead to
unpredictable results unless there is a well-established priority system
enforcing which program is allowed to write to the device at which time. The
advantage is that the FTP can now be developed separately and even by someone
other than the author of the communications program. There are variations
involving inter-process communication to add access control to the latter
system, but I will not go into further detail.
The system described here is based on Amiga shared libraries. The
library implements a small number of primary functions, such as "Send File(s)"
and "Receive File(s)". These functions are called with a single argument, a
pointer to an XPR_IO structure. This structure contains a number of things, the
more obvious one being a pointer to a null terminated string indicating which
files are to be sent or received and addresses of "call-back" functions inside
the code of the communications program to access the serial device, which is
opened typically in exclusive access. The scheme described here opens the
possibility for the Amiga community to write a multitude of file transfer
protocols, all rather small in size because they don't contain any overhead,
that work with any communications program following the rules outlined in this
document.
....
I would like to thank Marco Papa of Felsina Software for his help in
working out some of the details of the XPR standard.
---- end of quote
Have you all an enjoyable and safe forth of July.
-- Marco Papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=shf@well.UUCP (Stuart H. Ferguson) (07/09/89)
+-- papa@pollux.usc.edu (Marco Papa) writes: | XPR: External File Transfer Protocols as Amiga Libraries. | ========================================================= | [ ... ] This structure contains a number of things, the | more obvious one being a pointer to a null terminated string indicating which | files are to be sent or received and addresses of "call-back" functions inside | the code of the communications program to access the serial device [ ... ] Aha! More call-back functions. There are several places where these are going to become important in the future, and every package so far has its own idea about how they should be done. There may already be a BIX discussion about picking a standard way (if not, there should be!). XPR sounds like a great thing, but make sure to check out the evolving position on call-backs. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
papa@pollux.usc.edu (Marco Papa) (07/10/89)
In article <12626@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: |+-- papa@pollux.usc.edu (Marco Papa) writes: || XPR: External File Transfer Protocols as Amiga Libraries. || ========================================================= || [ ... ] This structure contains a number of things, the ||more obvious one being a pointer to a null terminated string indicating which ||files are to be sent or received and addresses of "call-back" functions inside ||the code of the communications program to access the serial device [ ... ] | |Aha! More call-back functions. There are several places where these are |going to become important in the future, and every package so far has its |own idea about how they should be done. There may already be a BIX discussion |about picking a standard way (if not, there should be!). XPR sounds like |a great thing, but make sure to check out the evolving position on call-backs. At this point is clearly too late in the game. There are people already writing XPR-based external protocols. 1.4 Intuition supports IHooks, another version of call--back technique, though I haven't seen it proposed as the "standard" way to do ANY kind of callback. Willy Langeveld, who originally develped XPR, is on BIX, so I am sure he has seen the discussions. A discussion on callbacks and standardazing them IS a good idea. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
darin@vogon.laic.uucp (Darin Johnson) (07/11/89)
In article <18362@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >At this point is clearly too late in the game. There are people already >writing XPR-based external protocols. 1.4 Intuition supports IHooks, >another version of call--back technique, ... In a similar vein, I had this wacky idea apropos to callbacks. (hit 'n' now if you don't like off the cuff and stupid ideas) I don't recall what made me come up with the idea, but after I thought of it, it dawned on me that it is very similar to UNIX SYSV streams. I don't know too much about streams, so pardon my BSD ignorance. Streams, as the name implies, is a device driver that takes its input (packets) and passes them to the output. However, it supports a protocol allowing you to specify a module to perform some actions on the data while it passes through the stream. In fact, you can build up a whole list of these 'filters'. The usefulness in this, is that you can take an existing device, say a network connection, and suddenly make it start doing something different, such as swapping bytes, keep track of the number of reads vs. writes, etc. I thought this would be a great idea for Amiga, but some ugly details made me forget about actually trying to implement it. What it would do, is allow you to do some preprocessing on DOS packets. The 'stream' device would take a DOS packet, send it to a module (a module could request a certain type), and that module would fiddle with it and then send it on to the 'real' device handler. Some examples (silly though they may be): A UNIX: device, that filters all open, examine, exnext packets so that "." and ".." in file names are interpreted. Each UNIX device would be associated with something like DF0, etc. Even more extreme, a VMS: device that reinterprets the entire path! A kermit style device to translate open, write, read, etc. to a kermit protocol on SER: The PATH: device could possibly be written using something like this, depending upon how versatile the 'stream' device is. The whole idea being, if you want to do something just a little bit different than an existing device, you don't have to create a whole new handler from scratch, just write some filtering routines. I don't know if UNIX streams do this, but the filtering routines could possibly stick around as a resident routine so that existing programs could make use of the 'new' device. By now, you all think I've flipped out. Probably right. Might be worth pondering though, for you pondering types. Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.