home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Fwd> Re> OSA Cross-platform Iss < prev    next >
Encoding:
Internet Message Format  |  1996-07-10  |  8.5 KB  |  [TEXT/ttxt]
  1. Subject:     Fwd> Re> OSA Cross-platform Issues
  2. Sent:        7/10/96 4:25 PM
  3. Received:    7/10/96 4:41 PM
  4. From:        David McCusker, david_mccusker@powertalk.apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Christopher Hunt (chris_hunt@yes.optus.com.au) writes:
  9. > I've been curious about OpenDoc's strategy for inter-part/task
  10. > communication on non-Mac platforms... could someone please elaborate
  11. > more on Gregs' points i.e. how will an OpenDoc part editor be expected
  12. > to communicate with other parts and tasks; simply through proprietary
  13. > interfaces?
  14.  
  15. Jon Pugh had something pretty interesting to say about cross platform
  16. OSA on the OpenDoc interest list earlier this afternoon.  I'm forwarding
  17. it to this list (it follows my signature).
  18.  
  19. Additionally, one might also note that OpenDoc's inter-part communication
  20. strategy allows for parts to roll their own without interference from
  21. OpenDoc.  We recommend using extensions to advertise your brand of
  22. inter-part communication.  Examining extensions requires making SOM calls.
  23. Waiting for DSOM simplifies the inter-process case for communiating with
  24. SOM objects.
  25.  
  26. David McCusker, OpenDoc Storage & Bento, david_mccusker@powertalk.apple.com
  27.  
  28. <JON PUGH>
  29. At 11:55 AM 7/10/96, Greg Friedman wrote:
  30. >A cross platform scripting implementation in ODF is conditional on
  31. >a cross platform scripting implementation in OpenDoc.
  32.  
  33. Greg is completely correct here, but then, that wasn't the issue.  ;)
  34.  
  35. It was initially hoped that we could get OSA ported as part of OpenDoc, but
  36. that hasn't happened.  It did get ported to OS/2 and the OSA is present
  37. there using REXX as their scripting language, but it has not made it to the
  38. Windows port and that doesn't look likely to happen, so we're pretty much
  39. screwed as far as the OSA is concerned.
  40.  
  41. What has happened is that OLE Automation is the dominant scripting
  42. architecture on Windows (surprise surprise surprise).  What we need then is
  43. a way to reconcile OSA (as used by AppleScript and other Macintosh
  44. scripting languages) and other alternative messaging systems, such as OLE
  45. Automation, Denali and DSOM.
  46.  
  47. What I've been doing is putting together a plan for replacing the messaging
  48. subsystem with an object based system which would reconcile these disparate
  49. views of the world.
  50.  
  51. Basically, we are creating a new SDL (Scripting Definition Language) which
  52. describes your part's scripting interface in terms of objects.  This is an
  53. absurdly simple language that includes some specific constructs for the
  54. various languages we need to support.  We are writing a parser which will
  55. read this and dump .idl, .cpp and .r files for a variety of
  56. implementations.  The first one we're doing is OSA with Denali right behind
  57. it and OLE coming in later.  The beauty is that all of these
  58. implementations will bottleneck on a single .cpp file per scripting object
  59. which developers will fill in with their implementation.  This will be a
  60. simple SOM object.  All the other files merely call this base
  61. implementation and translate between their general implementations and this
  62. specific one.  In addition, the parser will dump a complete aete resource
  63. for your part.
  64.  
  65. All of this is a work in progress with no timelines specified yet, but it's
  66. looking very good in design and there's actual work being done on it.  It's
  67. going to include a compatibility object which knows how to talk to parts
  68. using the current semantic interface, so there's no danger in losing
  69. functionality by implementing things now, but it will be a good deal easier
  70. to cope with all of theses issues when this is finished.
  71.  
  72. I don't know any of the issues regarding getting this accepted by IBM for
  73. the other versions, but technically, they were asking for this and it could
  74. probably be done fairly easily since it looks like the OSA is the most
  75. work.
  76.  
  77. At 2:03 PM 7/10/96, Bernie Wieser wrote:
  78. >Consider implementing an OpenDoc extension that exposes JUST THE CONTENT of
  79. >your part via SOM.  We did.  It's not recordable, but it is fast
  80. >("direct-to-som").
  81.  
  82. This is essentially what we are doing, plus we are automagically making the
  83. glue for all the various messaging systems at the same time.
  84.  
  85. I just wish I could snap my fingers and have it all working.  ;)
  86.  
  87. Jon
  88. </JON PUGH>
  89.  
  90.  
  91. ------------------ Nested Letter Follows ------------------
  92. At 11:55 AM 7/10/96, Greg Friedman wrote:
  93. >A cross platform scripting implementation in ODF is conditional on
  94. >a cross platform scripting implementation in OpenDoc.
  95.  
  96. Greg is completely correct here, but then, that wasn't the issue.  ;)
  97.  
  98. It was initially hoped that we could get OSA ported as part of OpenDoc, but
  99. that hasn't happened.  It did get ported to OS/2 and the OSA is present
  100. there using REXX as their scripting language, but it has not made it to the
  101. Windows port and that doesn't look likely to happen, so we're pretty much
  102. screwed as far as the OSA is concerned.
  103.  
  104. What has happened is that OLE Automation is the dominant scripting
  105. architecture on Windows (surprise surprise surprise).  What we need then is
  106. a way to reconcile OSA (as used by AppleScript and other Macintosh
  107. scripting languages) and other alternative messaging systems, such as OLE
  108. Automation, Denali and DSOM.
  109.  
  110. What I've been doing is putting together a plan for replacing the messaging
  111. subsystem with an object based system which would reconcile these disparate
  112. views of the world.
  113.  
  114. Basically, we are creating a new SDL (Scripting Definition Language) which
  115. describes your part's scripting interface in terms of objects.  This is an
  116. absurdly simple language that includes some specific constructs for the
  117. various languages we need to support.  We are writing a parser which will
  118. read this and dump .idl, .cpp and .r files for a variety of
  119. implementations.  The first one we're doing is OSA with Denali right behind
  120. it and OLE coming in later.  The beauty is that all of these
  121. implementations will bottleneck on a single .cpp file per scripting object
  122. which developers will fill in with their implementation.  This will be a
  123. simple SOM object.  All the other files merely call this base
  124. implementation and translate between their general implementations and this
  125. specific one.  In addition, the parser will dump a complete aete resource
  126. for your part.
  127.  
  128. All of this is a work in progress with no timelines specified yet, but it's
  129. looking very good in design and there's actual work being done on it.  It's
  130. going to include a compatibility object which knows how to talk to parts
  131. using the current semantic interface, so there's no danger in losing
  132. functionality by implementing things now, but it will be a good deal easier
  133. to cope with all of theses issues when this is finished.
  134.  
  135. I don't know any of the issues regarding getting this accepted by IBM for
  136. the other versions, but technically, they were asking for this and it could
  137. probably be done fairly easily since it looks like the OSA is the most
  138. work.
  139.  
  140. At 2:03 PM 7/10/96, Bernie Wieser wrote:
  141. >Consider implementing an OpenDoc extension that exposes JUST THE CONTENT of
  142. >your part via SOM.  We did.  It's not recordable, but it is fast
  143. >("direct-to-som").
  144.  
  145. This is essentially what we are doing, plus we are automagically making the
  146. glue for all the various messaging systems at the same time.
  147.  
  148. I just wish I could snap my fingers and have it all working.  ;)
  149.  
  150. Jon
  151.  
  152.  
  153.  
  154. ------------------ RFC822 Header Follows ------------------
  155. Received: by powertalk.apple.com with SMTP;10 Jul 1996 13:46:57 -0700
  156. Received: from CILabs.ORG ([199.182.213.62]) by mail-in1.apple.com
  157. (8.6.12/8.6.12) with SMTP id NAA17985 for
  158. <david_mccusker@powertalk.apple.com>; Wed, 10 Jul 1996 13:37:07 -0700
  159. Received: from localhost by CILabs.ORG (5.x/SMI-SVR4) id AA16352; Wed, 10 Jul
  160. 1996 13:42:12 -0700
  161. Received: from mail-out1.apple.com by CILabs.ORG (5.x/SMI-SVR4) id AA16315;
  162. Wed, 10 Jul 1996 13:35:35 -0700
  163. Received: from [17.203.32.142] (A17-203-32-142.apple.com [17.203.32.142]) by
  164. mail-out1.apple.com (8.7.5/8.7.3) with SMTP id NAA03814 for
  165. <OpenDoc-Interest@CILabs.ORG>; Wed, 10 Jul 1996 13:34:09 -0700
  166. Message-Id: <v02140b08ae09b99b18c7@[17.203.32.142]>
  167. Date: Wed, 10 Jul 1996 13:33:50 -0700
  168. Reply-To: OpenDoc-Interest@CILabs.ORG
  169. Sender: owner-OpenDoc-Interest@CILabs.ORG
  170. Precedence: list
  171. From: jonpugh@netcom.com (Jon Pugh)
  172. To: OpenDoc Related Technologies Interest List  <OpenDoc-Interest@CILabs.ORG>
  173. Subject: Re: OSA Cross-platform Issues
  174. Mime-Version: 1.0
  175. Content-Type: text/plain; charset="us-ascii"
  176. X-Sender: jonpugh@netcom3.netcom.com
  177. X-Url: http://www.infoworkshop.com/~jonpugh/
  178. X-Listprocessor-Version: 7.1 -- ListProcessor by CREN
  179.  
  180.  
  181. ------------------ End of Nested Letter ------------------
  182.  
  183.