home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / atari / st / tech / 6383 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!Sirius.dfn.de!zam103!djukfa11!hac041
  2. From: HAC041@DJUKFA11.BITNET (Konrad Hinsen)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Re: XAcc protocol definition
  5. Message-ID: <92357.133157HAC041@DJUKFA11.BITNET>
  6. Date: 22 Dec 92 13:31:57 GMT
  7. References: <92356.104533HAC041@DJUKFA11.BITNET>
  8.  <1992Dec21.205804.19515@netcom.com>
  9. Organization: Forschungszentrum Juelich
  10. Lines: 48
  11.  
  12. In article <1992Dec21.205804.19515@netcom.com>, ersmith@netcom.com (Eric R.
  13. Smith) says:
  14. >
  15. >The biggest problem that I see with the XACC protocol is the requirement
  16. >that data be passed in pointers; that's not a nice thing under MultiTOS,
  17.  
  18. I understand your dislike for pointers, but there are good
  19. reasons for them:
  20.  
  21. - it is not possible to send data objects of arbitrary size using
  22.   AES messages
  23. - it is more efficient to pass only pointers
  24.  
  25. Besides pointers are also used in other places (XBRA), so MultiTOS
  26. will have to provide a means for pointers across processes anyway.
  27.  
  28. >since it means that memory protection must be bypassed (with some care
  29. >one can restrict the memory protection bypassing to a specific memory
  30. >block, but I'm afraid that many programmers won't take this care). It
  31.  
  32. I have a bit more faith in application programmers, but you might be
  33. right. Perhaps this should be pointed out more explicitly in the
  34. documentation. At least I can assure you that all programs currently
  35. using this protocol allocate a buffer for the data to be passed
  36. by Mxalloc() without allowing access to other data.
  37.  
  38. >also makes any kind of networking difficult, although admittedly that's
  39. >a less serious concern at the moment since the AES doesn't support
  40. >networking.
  41.  
  42. Networking would require a complete new set of AES functions, so
  43. obviously there is no way to define data interchange protocols
  44. now in such a way that they would work unchanges with future
  45. networking versions.
  46. >
  47. >In MultiTOS there will be a drag and drop protocol specified, using
  48. >AES messages and MiNT pipes for communication.
  49. >
  50. Really? It has been announced for quite some time, but so far I have
  51. not seen anything more specific.
  52.  
  53. Anyway, this is a somewhat different problem. While drag&drop could
  54. be implemented using XAcc, the reverse is obviously not true.
  55. Besides XAcc was designed for standard TOS and can still be used there,
  56. which explains why it can't use pipes and other MiNT features. With
  57. this restriction, I see no way to avoid using pointers.
  58.  
  59. Konrad Hinsen (hac041@zam001.zam.kfa-juelich.de)
  60.