From: gblock@csd4.csd.uwm.edu (Gregory R Block)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: The HYDRA bidirectional file transfer protocol.
Date: 25 Jan 1993 01:08:15 GMT
Organization: University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.7.4
X-Newsreader: TIN [version 1.1 PL8]

In article <1993Jan23.182546.19169@cunews.carleton.ca>, Russell McOrmond (rmcormon@alfred.carleton.ca) wrote:
:   Filenotes are trivial to standardize, we just have to say "Sure,
: I'll do it that way".  With WPL it's totally user configurable.
: Inbound filenotes are already in heavy use by many different programs
: and there is no reason I can think of not to continue to use it.  If
: it ain't broke, don't fix it.

I just feel that it would be "more complete" if the queue management
was used both ways.

: (Unlike the current non multi-thread capable and/or address dependant
: methods for outbound handling such as UUCP C.#? or fonet #?.FLO files).

(agreed)

:   What is the PURPOSE of keeping track of inbound files?  For outbound
: files it is obvious that you need to know what files are to go where -
: For inbound the information can be gotten in any number of easier and
: more efficient methods  (Changing inbound directories, filenotes, etc,
: etc).

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
some filesystems.  A tosser could simply say "give me all inbound
stuff that corresponds with the following UUCP/Fido/GeekNet address:",
and that would be it.  No worrying about special cases, it's
extensible, etc.

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
invaldates its use.  Especially since there's a very good chance that
someone would WANT to use that filesystem.

:   You'd have to do a lot of convincing (Or write the code yourself
: <grin>) before I'd add 'inbound tracking with XferQ) into WPL as I
: don't see the purpose.

I don't have an immediate use for such things, however, I could easily
find it helpful in the future.  When the time comes, I may.  :)

:   I will be doing that in the WPL programmers manual - With XferQ I'm
: just a user.

Okey.  :)

:   The file request shell and WPL have nothing to do with each other,
: except that a WPL based mailer will be compatable with the request
: shell.  There is absolutely no direct communication between this

Right.  The request shell is purely a function of XferQ.

: request shell and WPL (BY DESIGN) so that if any other mailer author
: added XferQ support to their mailer this request shell, and all
: compatable file request handlers will automatically work.

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

The existence of Xtools/Qtools/XQtools/whatever is important because
at first, I'm not sure if there will be any mailers that support the
XferQ standard.  Will there be a FlowConvert-like utility available
upon release of XferQ, or will that come later?

:   The FREQ shell's sources will be released public domain so that any
: file request program author can just include code out of it and make
: the request shell's use obsolite with their request handler.

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

Greg

--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
(: "Just because Workbench isn't painted like a pimp's BMW doesn't    :)
(:  mean it's not sharp, elegant, and functional."    -Ian Kennedy    :)
(: (: (: (: (: (: (: (: (: (: (: (: (:) :) :) :) :) :) :) :) :) Wubba :)
Newsgroups: comp.sys.amiga.datacomm
From: mlednor@tower.demon.co.uk ("Mark J. Lednor")