home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2279 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: sdd.hp.com!inn
  2. From: Jeff Grimmett <jgrimm@sdd.hp.com>
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: YASL (was: AsynchIO (was: fastest file read method ??))
  5. Date: 29 Jan 1996 19:50:05 GMT
  6. Organization: Hewlett-Packard Company
  7. Message-ID: <4ej8dd$hi1@news.sdd.hp.com>
  8. References: <w9YbsMD4ACazz9@jeff.dame.shnet.org> <w+RYXMD4FC8aRz1@_crisi.blackbox.shnet.org> <4dsalp$t68@news1.halcyon.com> <4du0ju$84b@news.sdd.hp.com> <4e2e76$9k3@toad.stack.urc.tue.nl> <4e3j8v$jd0@news.sdd.hp.com> <4e7si4$ore@tuegate.tue.nl> <4e8asc$rht@news.sdd.hp.com> <1349.6599T1259T2701@amiga.pp.se> <4egkuh$j1q@news.sdd.hp.com> <19960129.40EA00.9A87@am174.du.pipex.com>
  9. NNTP-Posting-Host: hpsdv330.sdd.hp.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.2N (Windows; I; 16bit)
  14.  
  15. m.hendry@dial.pipex.com (Mathew Hendry) wrote:
  16.  
  17. >: I'd just like to see a little judgement used by developers, is all.  If 
  18. >: there's no real compelling reason to put it in a library, it shouldn't 
  19. >: be.  But, if you do, DOCUMENT IT and make the required files available to 
  20. >: other developers so that it is NOT a waste.
  21.  
  22. >So your judgement is that the AsyncIO routines should NOT be in a shared
  23. >library. Why is this?
  24.  
  25. I thought I was sufficiently vague on that, but alas... no.  My feelings 
  26. on AsynchIO in a shared library is that if it were used sufficiently, it 
  27. should be.  At this point, I have downloaded and/or ftp'd a grand total 
  28. of zero programs that require the shared library.  I have one program 
  29. that to my knowledge uses the linked library, but that's simply because I 
  30. know the author.
  31.  
  32. My MAIN reservation in this SPECIFIC case is that, as I understand it, 
  33. AsynchIO was a CBM/CATS released archive.  The archive I have does not 
  34. contain a shared library.  Either my version is old, or else the one with 
  35. the shared library is bogus.  I'm perfectly willing to admit the former, 
  36. as the version I have required a fix to operate properly.
  37.  
  38. >Several points which you should consider are:
  39.  
  40. >1. It IS well documented.
  41.  
  42. Yes, quite.
  43.  
  44. >2. The library (AsyncIO.library) is tiny - under 3k.
  45.  
  46. Never seen it.  I'll take your word on it.
  47.  
  48. >3. It would be a useful addition to many types of program (in fact, just about
  49. >   any program which uses disk I/O).
  50.  
  51. I've had it for 2 years.  ONE program I've written made use of that, and 
  52. I took it back out because the speed increase wasn't sufficient enough to 
  53. be worth it.
  54.  
  55. I won't deny point 3, just saying it hasn't demonstrated as much promise 
  56. as it would appear to.
  57.  
  58.  
  59. >4. Due to point 3, it IS beginning to appear in many different programs. This
  60. >   means that space savings (such that they are for a 3k library ;) and ease
  61. >   of update are already becoming points in it favour.
  62.  
  63. Who IS updating it?  Are we talking about the same archive?  
  64.  
  65. >You might say that point 2 is a justification for using the link library
  66. >version instead, but that method requires a recompile for every update of the
  67. >library's functions. Wasted effort, if you ask me.
  68.  
  69. Again, who's updating it?  The archive I have was issued by CATS.  They 
  70. no longer exist and it doesn't appear that ATG's team is quite yet on the 
  71. case.
  72.  
  73.  
  74. Slightly off the topic here, but maybe if it's a sufficient improvement, 
  75. its routines should replace the current ones for file I/O in future revs 
  76. of the OS.
  77.  
  78.  
  79.