home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / dsptchb1.zip / readme.b1 < prev    next >
Text File  |  1997-06-04  |  7KB  |  167 lines

  1. Dispatch started as an exercise in socket programming with Object REXX.
  2. There is virtually no socket documentation comprehensible to a
  3. non-programmer -- especially someone who cannot even read C. So I used a
  4. freeware REXX pop client I found on Hobbes as a model.  It did not work --
  5. OREXX is more intolerant of extra 'END' statements than TREXX.  But at
  6. least I understood the general structure.  There is little of that program
  7. left in mine now.
  8.  
  9. As for protocols, I found that RFC's are easier to understand that I had
  10. expected.  So I wrote a bunch of little utilities:  One to receive mail via
  11. POP -- into a unique folder for each message with all attachments detached.
  12. One to send mail via SMTP with files appended.  One to post news.  One to
  13. download an entire newsgroup.  Etc.
  14.  
  15. The other day, I decided to combine three of these into one.  The result is
  16. Dispatch.
  17.  
  18. Dispatch is a compiled OREXX program.  It will only run under Warp 4.0 or
  19. on a system with Object REXX installed and active.  It uses REXXLIB
  20. utilities and two shareware packages for mime and uuencoding.  I will
  21. eventually write both into my program.  (I have the Base64 model I need, but does anyone have a REXX UUencoding model?)  It also uses the excellent
  22. SofTouch TCPIP functions.
  23.  
  24.  
  25. WARNING
  26.  
  27. All three of these functions have been somewhat tested as free standing
  28. modules.  FTP, however, was an afterthought and has not been tested since
  29. it was added.
  30.  
  31. There is only primitive error detection and handling.  This program crashes
  32. easily and cryptically.  But since it is a simple command line utility, it
  33. usually does no harm -- and tells you that it has died.
  34.  
  35. BUT -- I will not be responsible for any damage of any kind that results
  36. directly or indirectly from your use of this program.  You are warned that
  37. I am a novice programmer and that this is an experiment.
  38.  
  39. FUTURE PLANS
  40.  
  41. Add fax dispatch support.  (I already posted a utility to do this, FxShell.
  42. I will integrate it.)
  43.  
  44. Add optional, simple GUI for the functions.
  45.  
  46.  
  47. THE INTELLIGENT QUEUE
  48.  
  49. I am rather proud of this feature -- although I have no idea if it actually
  50. adds to performance.  At least I got it to work.
  51.  
  52. The original model I had to work with used LINEIN and LINEOUT methods.  The
  53. pop client went like this:
  54.  
  55. Grab a handful of data from the socket Parse out the first line (by looking
  56. for a CRLF) Save it using LINEOUT. Parse out the second line Save it Etc.
  57. Etc.  Retain the last bit of data in the buffer if it is a partial line
  58. Grab another handful of data from the socket.
  59.  
  60. The program forgot to strip off any dot ('.') which begins a line.  This
  61. would add more overhead.
  62.  
  63. It seemed to me that, even at disk access speeds, this method must add
  64. overhead.  So I tried to create an Object REXX Queue object with built in
  65. logic.
  66.  
  67. My intelligent Queue is a subclass of the standard queue object.  My pop
  68. client, for example, does the following in place of what I described above:
  69.  
  70. Gets a bunch of data off the socket.  Checks to see if it has the EOF
  71. marker at the end.  Queues it on the intelligent queue Gets another bunch
  72. of data off the socket Etc.
  73.  
  74. Meanwhile, the queue process has been started as a concurrent process.  It
  75. pulls data off itself, looks for dots that need stripping (without parsing
  76. the data into lines) and saves the data using CHAROUT.
  77.  
  78. The program you are about to use uses the same idea.  The intelligent queue
  79. reads in data in 10,000 character chunks.  It pads any beginning of line
  80. dots with dots.  It queues the data on itself and goes back to the file for
  81. more.  Meanwhile, the main process which created the queue starts pulling
  82. data off the queue and sending it out.
  83.  
  84. It is fast.  With text files I have peaked at 115200 -- my port speed.
  85.  
  86. The most recent version of this program uses similar queues for moving
  87. temporary data around.  For example, I use mpack to make base64 files, but
  88. strip off the headers and boundaries.  To do this, I used to make a
  89. temporary file and then copy it line by line onto the target file,
  90. stripping out unwanted data.  Now, I let an intelligent queue do the
  91. processing and use CHARIN and CHAROUT.  It is certainly faster than it was,
  92. but I have no idea if the queue adds anything at all.
  93.  
  94. DOSFILE
  95.  
  96. There is one other aspect to this program I should mention.  I use a
  97. version of a class I am working on called DOSFile.  It is an enhanced
  98. subclass of the Stream class.  Instances of the DOSFile class have all the
  99. methods of the stream class plus:  they can copy or move or delete or
  100. create themselves, parse their paths, etc.  When it moves itself (or,
  101. optionally, when it copies itself) it allows one to move its focus to the
  102. new physical file.  Let me explain:
  103.  
  104. MyFile = .DOSFile~new('c:\example1.txt')
  105.  
  106. Yields a REXX instance of the .DOSFile class.  It is manipulated by
  107. reference to the MyFile variable.  You get data out, for example, by using:
  108.  
  109. line = MyFile~linein
  110.  
  111. (I guess if it were REALLY object oriented they would have used LINEOUT,
  112. but that would have created too much confusion.)
  113.  
  114. Let's say I need to move the underlying disk file into a directory.  I
  115. might write:
  116.  
  117. MyFile~move('c:\temp\example2.txt','R','V')
  118.  
  119. MyFile now refers to c:\temp\example2.txt
  120.  
  121. So MyFile~delete, deletes the new file.
  122.  
  123. Or, let us say I want to copy data from example1.txt onto example2.txt and
  124. start dealing with the target file instead of the source file.
  125.  
  126. MyFile~copy('example2.txt','A','V','COPY')
  127.  
  128. appends the data from MyFile onto example2.txt and then switches the focus
  129. of MyFile to example2.txt.
  130.  
  131. The free standing version of DOSFile also includes methods for the file to
  132. zip itself, email itself, fax itself, base64 encode itself, etc.  In light
  133. of what I have learned from writing Dispatch I will have to rewrite DOSFile
  134. completely.  It was intended to make programming easier.  I am not
  135. completely satisfied with it from having used it, but the idea works and I
  136. will continue work on it.
  137.  
  138. LICENSE
  139.  
  140. This grants you a license to experiment with this program at your own risk
  141. until it is withdrawn.  The license will be deemed withdrawn upon release
  142. of any shareware or commercial version of the product.
  143.  
  144. FEEDBACK
  145.  
  146. Feedback is solicited.  But be gentle.  I wrote my first OREXX program only
  147. three months ago and my first real REXX program only a year ago.  And it is
  148. hard to teach old -- 50 yo -- dogs new tricks.
  149.  
  150. INSTALLATION
  151.  
  152. Almost forgot this part.  Put Dispatch anywhere you want.  Activate OREXX
  153. -- See the Warp 4 README Copy the GRXTCPIP.DLL to a directory in your
  154. LIBPATH.  Install the REXXLIB DLL contained in the Demo package enclosed.
  155. Install MPACK and UUENVIEW to directories in your PATH.
  156.  
  157. Chris Barr
  158. cbarr@ibm.net
  159.  
  160. PS
  161.  
  162. I forgot the following --
  163.  
  164. FTP -- the default mode is text. For binary, prepend the name
  165. of the file to send with an * just as a mime file is in mail:
  166.  
  167. -F*dsptcha1.zip