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

Text File | 1993-01-21 | 5.4 KB | 117 lines

Newsgroups: comp.sys.amiga.datacomm
Path: sparky!uunet!cs.utexas.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: Thu, 21 Jan 1993 17:45:07 GMT
Lines: 107

 In article <[e-mail]> [e-mail] (Gregory R Block) writes:
 >conflicts between you guys, anyways, and if my aging memory serves me,
 >I do remember some protocol problems between Welmat and Binkley, a

 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 do hope that someone is able to coerce an xprJanus out of that
 >source.

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

 >Of course, with an xpr comes the need for systems that SUPPORT
 >bi-directional XPR's.  How goes that committee?  :)  Has a new
 >standard evolved?  (it's been a while since I "checked in" on it.)

   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.

 >like WPL (or Welmat to non-beta testers) are adding more power to the
 >Mailer scene than the Trap crew could ever HOPE for.  WPL is totally

   Now who's pushing negative politics?  Please put disclaimers on
 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
 is useless to them, support for future XPR libraries and xferq will
 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.


 >open, and it's going to revolutionize the "frontend" community for
 >UUCP and FidoNet systems alike.

   This may be true, but it's also going to push other authors forward
 which is a good thing.
 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.

   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'm concerned it's always been the third party utilities that become
 'Mailer XXX only' that has caused various problems - It would be nice
 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.

 >Nobody knows anything about NewsManager, so don't ask.  :)  Boy, I
 >feel better now that the politics are out of the way.

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

 >whatever reasons, flow.library never took off, whether due to its

   There are three things an outbound handler should do:
   a) allow for shared access to the outbound list in a semaphore
 protected environment.
   b) Allow for transparant extensions of the IMPLEMENTATION while
 remaining backward compatable.  Internal structures should therefore
 be hidden.
   c) Be easy to use and well documented.


 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.

 >on.  Ask Mr. XferQ if he'd do a comp.sys.amiga.announce post when it's
 >finished, just to let people know what it is, that it exists.  These

   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 not "yet another library" like all of those file requester
 >libraries.  :)

   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!

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

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