NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/amiga/datacomm/8974

Text File | 1993-01-27 | 4.1 KB | 86 lines

Newsgroups: comp.sys.amiga.datacomm
Path: sparky!uunet!think.com!spool.mu.edu!torn!nott!cunews!rmcormon
From: [e-mail] (Russell McOrmond)
Subject: Re: The HYDRA bidirectional file transfer protocol.
Message-ID: <[e-mail]>
Sender: [e-mail] (News Administrator)
Organization: Carleton University, Ottawa, Canada
References: <[e-mail]> <[e-mail]>
Date: Tue, 26 Jan 1993 19:29:16 GMT
Lines: 76

In article <[e-mail]> [e-mail] (Gregory R Block) writes:
>Unless, of course, you'd prefer not to hassle with multiple inbound
>directories, and again, the existence of no solid standard on
>filenotes which may be trashed by some programs, and may not exist on

  You're missing the point, and that is 'ease of use'.  Since many
systems, many that don't even know of the existance of XferQ are
*ALREADY* using filenotes, no expansion is required.

  For instance, someone can use the EXISTING GCCHost which uses
filenotes, turn on a mode where it generates 4D .OUT files, and just
JBun2 to compress things up and you're laughing - No direct support is
required in GCCHost (Which is a bonus as most authors don't know about
XferQ yet and there will be many people wanting to use it right away).

  I suspect that a majority of the XferQ compatable software for a
long while will be a 'configuration option' where it will allow you to
generate old style 2-D or 4-D .FLO files, or to talk to XferQ.  The
additional code for someone who is already configurable is trivial.

>Just because there are simple solutions available NOW doesn't mean
>there always will be, and that's the whole point of setting up open
>standards.  The nonexistence of filenotes on some filesystems

  XferQ relies on something that's not easily available in most
operating systems, shared libraries.  We're talking about Amiga
specific things here for the moment.  If I decide to port WPL, XferQ
and other things over to another operating system, I can design
something appropriate at that time.  If a BSD based mailer requires
special inbound file management, I can do it for the BSD version of
the system, not for the AmigaDOS version which already has a very well
used method of passing this information around.

>Right.  That's the point.  :)  Just because I refer to it in terms of
>it being useful in combination with the WPL mailer doesn't mean I
>don't realize that it's based in XferQ.  :)

  This is a Public conference, a broadcast discussion.  The reason I'm
involved is to get people to understand what the issues are.  If I
were just talking to you, this would be in Email.  Making sure that
the information passed in this public conference is as correct as
possible is an important issue.

>XferQ standard.  Will there be a FlowConvert-like utility available
>upon release of XferQ, or will that come later?

  As with all other tools, neccesity creates utilities.  None of the
current people associated with XferQ have any use for .FLO files, so
no utility has yet been written.  I suspect that a utility will be
written when someone sees the need for it.

  It would not be all that hard to write, but since someone else would
have to do all testing on it, it would be better if that same person
wrote/debugged it themselves.  I myself haven't seen a .FLO file in
years.  (It's bad enough I currently see C.#? files in UUSPOOL:,
ulthough I'll solve that one fairly soon as well - No more problems
with slow directory scans on busy sites).

  Myself, I run a FTN tosser/scanner that generates .OUT files which JBun2
compresses/manages for me, and I run a Tick processor written in AREXX
which has already been ported to use XferQ.

>:)  Good idea.  Releasing it GPL would simply impose restrictions, and
>right now it's important to get widespread incorporation.

  This is the one case where I want 'commercial' type people to be
able to 'take from the pot without doing anything in return'.

---
 Russell McOrmond, Ottawa Ontario, Canada    | Standard Disclaimer applies.
 Freenet: [e-mail] (Faster) | WPL 'keeper of sources'.
 Home: [e-mail],  1:163/109   | Libertyware Telecomunications.