NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/amiga/datacomm/5971

Internet Message Format | 1992-08-30 | 6.5 KB

Path: sparky!uunet!utcsri!torn!cunews!revcan!sidus!atronx.OCUnix.On.Ca!rwm
From: [e-mail] (Russell McOrmond)
Message-ID: <[e-mail]>
Date: 29 Aug 92 09:17:59 EST
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Amiga Comms (was RE: Amiga Kiosks?)
In-Reply-To: [e-mail] (Jesper Kehlet)
References: <[e-mail]>
    <[e-mail]>
Lines: 116

[e-mail] (Jesper Kehlet) writes:
>The difference is really not that great.  But when you call library
>functions, you lose to major overhead on those and that's bad!

  I don't know what compiler you are using, but the stack-requirements of
doing a procedure call are often greater than the optimizations that SAS
can do when setting registers for a library call.  I would think that the
overhead, if it exists at all, is a minor issue considering the number
of other O.S. calls one does in their software anyways (Which goes through
the same library inteface).

>No matter, how you do it, built-in protocols will, if written properly,
>always be more efficient than the XPR ones.

  How?  Lets get extremely specific?  By the same token, an MS-DOS box which
isn't using a fossil driver will always be faster than an Amiga who has to
go through a 'device' (==library) interface in order to talk to the modem?
So, for the same reason we should 'not' be using XPR's, we should not be using
serial.device, and we should be hard-coding to the hardware?  Funny, last
time I checked JRComm was even still talking through the .device interface ;-)

>When I do a fast, small and efficient Zmodem implement, I still have to pay
>my bills.  When I announce it as a being a good Zmodem implement and it IS,
>then people will, if not pay more, then at least pay for it!

  I'm curious what this has to do with XPR?  I'm not suggesting that nobody
should make money writing software, all I'm ever suggesting is that people
offer more choices in the 'format' of their products.  In most
other situations, people consider a library interface as an ADVANTAGE instead
of the dis-advantage people 'seem' to think it is with transfer protocols.

  BTW: I think you are confusing the Chuck Forresberg Zmodem issue with the
XPR issue.  Eithor that, or I didn't understand what you were trying to
refer to with the above text.

  P.S.  The software that I write 'costs' just like anything else.  It's just
that I have a 'customer' (Which happens to mostly be myself and a few other
close supporters) and don't feel that it's the 'software' that I'm selling, but
the support.  I still SELL support, and expect to get paid one way or another
for my work.  Any Welmat user can attest to the fact that I listen to
'supporting' users and other developers (Who can support via writing code) a
lot better than just 'some Joe who wants to use some software, but doesn't
have any money/time to spend' ;-)

>>   If everyone wants better protocols, encouraging authors to support XPR
>> (On both sides of the interface by writing XPR's themselves as well), we'll
>> all be better off.

>Except for those of us considering overhead and flexibility.

  Give me specifics!  How can allowing the users access to more protocols in
a method where THEY can add what they want be considered 'less flexible'.
You're talking to a person who is writing a Telecom LANGUAGE for a network
mailer, so flexability and configurability are one of the largest reasons
I am SUPPORTING XPR.


  Since you haven't given any real data yet, I'll start discussions by
giving you my current gripes with XPR:

  a) There is no way for a 'host' to mandate a certain 'level' for the
libraries that it opens.  Unlike where the XPR itself can read
the xpr_extension and the XPR_IO fields to determine what callbacks exist,
the host cannot determine whether a library will USE these extensions.

  b) The success/failure of an individual file transfer in a batch is not
given. What XPR badly needs is a 'success' parameter to be passed to
the xpr_fclose() call.  This can easily be added as an extension where
a new 'xpr_fclose_status()' can be added to give that functionality.
(You don't want to know the 'assumptions' I have currently
had to make in Welmat to determine file transfer success).

  c) Knowledge of 'what direction' (Upload/download/config reading?) is not
really  clearly given when staring a transfer.  Many XPR's use opening
of a file in 'read' mode as a method to check the existance of a file
(xpr_finfo() should be upgraded to include an 'exists'), and it would be
nice to know that all these opens are related to the 'same transfer'.
Having a callback that sets up the 'direction' of a transfer for a
specific file would allow things like directories to be added, security
dealt with/etc without any problems.  (It's private knowledge to the host
where a file is actually going to be placed, the XPR has no reason to
actually know).

  d) No facility to make use of the TermArray[] handling exists with the
current XPR interface.  This interface makes many 'escape' based protocols
considerably more efficient.  The least CPU intensive Zmodem is going to be
the one that makes use of this standardized Amiga serial device feature.

  e) While it is not a personal gripe, many complain about the non-existance
of asynchronous read/writes to the file/serial.  Personally I feel this is
solved by having a more intellegent HOST, but that's another issue to be
discussed.  Adding an asynch write, and a 'check status of last write' calls
could again easily be added as xpr_extension's (And one version of this
has already been done on the Xenolink BBS system)



  Now, rather than deciding to limit my users to the protocols I have time to
write, or limiting the protocols to only being usable with my own HOST, I
would rather work with other authors to get the remaining problems out of
the XPR interface.

  If you are interested in helping work towards a possible 'XPR 3.0'
specification, please let me know.  I'd like to get a group together with
different transfer needs (IE: I'm a mailer author, not a BBS or Terminal
package author) so that things can be improved for everyone.

>Hey, I'll start it for him...  8-d:-)

  I need DATA to consider this an actual flame-war or discussion ;-)

>     Jesper Kehlet, Compos Mentis Software Systems -- A Kind Of Magic
--
  Opinions expressed in this message are my Own. I represent nobody else.
  Russell McOrmond  [e-mail] Net Support:[phone](V.32Bis)
  FidoNet 1:163/109 Welmat Help 1:1/139  Current WELMAT 'keeper of sources'.