home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / amiga / datacomm / 8937 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  4.0 KB
  1. Path: sparky!uunet!wupost!uwm.edu!csd4.csd.uwm.edu!gblock
  2. From: gblock@csd4.csd.uwm.edu (Gregory R Block)
  3. Newsgroups: comp.sys.amiga.datacomm
  4. Subject: Re: The HYDRA bidirectional file transfer protocol.
  5. Date: 25 Jan 1993 01:08:15 GMT
  6. Organization: University of Wisconsin - Milwaukee
  7. Lines: 80
  8. Message-ID: <1jvehvINNman@uwm.edu>
  9. References: <1993Jan23.182546.19169@cunews.carleton.ca>
  10. NNTP-Posting-Host: 129.89.7.4
  11. X-Newsreader: TIN [version 1.1 PL8]
  12.  
  13. In article <1993Jan23.182546.19169@cunews.carleton.ca>, Russell McOrmond (rmcormon@alfred.carleton.ca) wrote:
  14. :   Filenotes are trivial to standardize, we just have to say "Sure,
  15. : I'll do it that way".  With WPL it's totally user configurable.
  16. : Inbound filenotes are already in heavy use by many different programs
  17. : and there is no reason I can think of not to continue to use it.  If
  18. : it ain't broke, don't fix it.
  19.  
  20. I just feel that it would be "more complete" if the queue management
  21. was used both ways.
  22.  
  23. : (Unlike the current non multi-thread capable and/or address dependant
  24. : methods for outbound handling such as UUCP C.#? or fonet #?.FLO files).
  25.  
  26. (agreed)
  27.  
  28. :   What is the PURPOSE of keeping track of inbound files?  For outbound
  29. : files it is obvious that you need to know what files are to go where -
  30. : For inbound the information can be gotten in any number of easier and
  31. : more efficient methods  (Changing inbound directories, filenotes, etc,
  32. : etc).
  33.  
  34. Unless, of course, you'd prefer not to hassle with multiple inbound
  35. directories, and again, the existence of no solid standard on
  36. filenotes which may be trashed by some programs, and may not exist on
  37. some filesystems.  A tosser could simply say "give me all inbound
  38. stuff that corresponds with the following UUCP/Fido/GeekNet address:",
  39. and that would be it.  No worrying about special cases, it's
  40. extensible, etc.
  41.  
  42. Just because there are simple solutions available NOW doesn't mean
  43. there always will be, and that's the whole point of setting up open
  44. standards.  The nonexistence of filenotes on some filesystems
  45. invaldates its use.  Especially since there's a very good chance that
  46. someone would WANT to use that filesystem.
  47.  
  48. :   You'd have to do a lot of convincing (Or write the code yourself
  49. : <grin>) before I'd add 'inbound tracking with XferQ) into WPL as I
  50. : don't see the purpose.
  51.  
  52. I don't have an immediate use for such things, however, I could easily
  53. find it helpful in the future.  When the time comes, I may.  :)
  54.  
  55. :   I will be doing that in the WPL programmers manual - With XferQ I'm
  56. : just a user.
  57.  
  58. Okey.  :)
  59.  
  60. :   The file request shell and WPL have nothing to do with each other,
  61. : except that a WPL based mailer will be compatable with the request
  62. : shell.  There is absolutely no direct communication between this
  63.  
  64. Right.  The request shell is purely a function of XferQ.
  65.  
  66. : request shell and WPL (BY DESIGN) so that if any other mailer author
  67. : added XferQ support to their mailer this request shell, and all
  68. : compatable file request handlers will automatically work.
  69.  
  70. Right.  That's the point.  :)  Just because I refer to it in terms of
  71. it being useful in combination with the WPL mailer doesn't mean I
  72. don't realize that it's based in XferQ.  :)
  73.  
  74. The existence of Xtools/Qtools/XQtools/whatever is important because
  75. at first, I'm not sure if there will be any mailers that support the
  76. XferQ standard.  Will there be a FlowConvert-like utility available
  77. upon release of XferQ, or will that come later?
  78.  
  79. :   The FREQ shell's sources will be released public domain so that any
  80. : file request program author can just include code out of it and make
  81. : the request shell's use obsolite with their request handler.
  82.  
  83. :)  Good idea.  Releasing it GPL would simply impose restrictions, and
  84. right now it's important to get widespread incorporation.
  85.  
  86. Greg
  87.  
  88. --
  89. (: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
  90. (: "Just because Workbench isn't painted like a pimp's BMW doesn't    :)
  91. (:  mean it's not sharp, elegant, and functional."    -Ian Kennedy    :)
  92. (: (: (: (: (: (: (: (: (: (: (: (: (:) :) :) :) :) :) :) :) :) Wubba :)
  93.