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

In article <1993Jan21.174507.24478@cunews.carleton.ca>, Russell McOrmond (rmcormon@superior.carleton.ca) wrote:
:  There were protocol problems between Binkley and Binkley at one time,
:  but these have been resolved (Right about the time of the release of
:  FTS-0007).

I knew there was SOMETHING like that.  :)  I've got to do something
about my long-term memory.  Like buy more memory, or perhaps a bigger
HD.  :)

:    An XPR had been started, but I'll let the authors comment as they
:  may have changed their mind.

Who are the possible authors?

:    The XPR mailing list has quietened down - I think we need to just go
:  ahead and implement some ideas.  We all seem to be waiting for someone
:  else to agree with an idea rather than just going for it and getting
:  it documented.

Ahh.  Okay.  Got an update on that document you had at one time?  Have
the changes already been implemented into WPL?

:    Now who's pushing negative politics?  Please put disclaimers on

I _REALLY_ should have put a smiley on that one.

:  statements like the above as I don't want to get the negative flack
:  for it.  I would also like to see some compatability form between WPL
:  and the utilities that the 'Trap crew' are writing.  While WPL itself

I'd like to see trap support XPR's.

:  is useless to them, support for future XPR libraries and xferq will

(speak of the devil.  :)  I'd _LOVE_ to see TD support XferQ.  We know
they're reading, so maybe he'll see this note and reply.

:  give those third party authors a larger users base.  It would be nice
:  for someone to be able to implement a HYDRA, JANUS, or whatever
:  protocol and instantly have a HUGE installed users base with
:  practically all fidonet systems,terminal packages and BBS packages
:  being able to support the protocol.

Agreed.  And support for XferQ would be a big step in the way of
getting programs out there that are capable of using things in this
format.  It's the most extensible soltuion to the in/outbound queues yet.

:    This may be true, but it's also going to push other authors forward
:  which is a good thing.

Lets hope so.

:  With the missing EMSI and Zmodem in the old application 'Welmat', the
:  Trap crew had it easy.   It will be interesting for everyone to see
:  what ideas start to come out with the release of WPL.

I'd say, as a guess, only those who were't dependent on their Fido
systems were still willing to use it (on the lesser end, many
multilines and those who simply liked the program or the price).  Now
that the stakes are much more "even", we'll have to see what people
think.  Hopefully, it'll spark life back into the game.  Development
for the networks needs to grow by leaps and bounds.  It's been a while
since I've had any kind of presence in the Fido community, and a
viable cross-network system STILL doesn't exist.  Hopefully, the
current suite of GPL stuff will change that.

:    A very POSITIVE thing that could happen is that some standards could
:  form for mailer interfacing (Such as XPR and XferQ support in other
:  front ends) that will remove (as far as I am concerned) all of this
:  silly animosity that exists between various mailer authors.  As far as

I had meant that as a joke, I really wish I hadn't phrased it that
way.  Upon re-reading, it did look a little rough.

:  I'm concerned it's always been the third party utilities that become
:  'Mailer XXX only' that has caused various problems - It would be nice

Yup.

:  to be able to work TOGETHER with the Trap crew on things.  Hopefully
:  once it has been very well debugged the Trap crew will consider
:  supporting Xferq (Whether by their own implementation of the interface
:  or not) in their Mailer and Tosser/scanner software.

Lets hope that acceptance of XferQ will be high.

:    Are politics out of the way, or did you just introduce it yourself?

I hope not.  I just like to joke.  :)

:  Flow.library addressed the first point, but failed miserably for the
:  other two points.  One of the best things I will be doing (And am
:  currently involved in debugging) for WPL is to get rid of
:  flow.library.  I do suspect that now that a proper outbound handler
:  exists, that the popularity of it will grow.

Agreed.  :)  XferQ's got everything that flow.library doesn't.

:    I will definetely be doing anything that I can to encourage people 
:  (expecially other mailer authors as that will solve the 'chicken and
:  egg' problem by handing out eggs) to support the library.  The same
:  thing will be attempted with the new XPR documentation once we finally
:  decide on things.

Are you still going to end up writing all of the documentation's code?
Preliminary documentation has been extremely thorough.  The autodocs
could have used a "bit more", but they were relatively good.

:    Hmmm - Trying to start another argument with someone?  Not a good way
:  to try to encourage support for something new.  Let's look at things
:  positively rather than negatively and hope that things go well!

Yeah, I'm beginning to see that all of these jokes I like to crack are
going to get me in trouble.  :)  Ah well.  Lets hope that I don't make
things worse.

We could always remove this, and take it to email.  At least there
nobody'll snarl at my jokes.  :)

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