home *** CD-ROM | disk | FTP | other *** search
/ Kosovo Orphans' Appeal Charity CD / KosovoOrphansAppeal.iso / commercialdemos / claresmicrosupplies / pca / docs / intro next >
Text File  |  1996-08-20  |  8KB  |  161 lines
  1. Plug In Compliant Application protocol
  2. ======================================
  3.  
  4.  
  5.  
  6. Introduction
  7. ============
  8.  
  9.  
  10. The Clares Plug In Compliant Application (PCA) specification provides an
  11. easy to implement way of allowing multiple applications to share common
  12. objects residing in shared memory areas. A program written to the PCA
  13. specification will work with any other which supports the standard and uses
  14. the same type of objects.
  15.  
  16. What does PCA do for me as a user ? 
  17.  
  18. The PCA standard works at two levels. In each case a document in a common
  19. memory area can be 'shared' between two or more applications. This is not
  20. like the versions of OLE implemented on the Acorn platform. There is a major
  21. difference in that OLE copies the document for the second application to
  22. work on, thus your data takes up twice as much RAM. With PCA all
  23. applications work on the same document thus incurring no RAM overheads.
  24.  
  25. The controlling application is called the Local application and the slave
  26. application is called the  Remote application.
  27.  
  28. When a document is edited in a Remote application the object in the Local
  29. application is automatically updated.
  30.  
  31. What we have up to now is a more efficient way of doing OLE. However, PCA
  32. does not stop there. Take an application like Composition which provides a
  33. page make up environment for bit image and vector images - all of which can
  34. be moved and edited - a bit like Draw for bit images but with a LOT of
  35. extras. Composition does not provide 'painting' tools but ProArtisan 24
  36. does. If both applications are PCA compliant then a Utilities menu in Compo
  37. will show ProArt 24 as a 'tool'. Clicking on this menu entry opens a PA24
  38. window showing the selected Compo object. PA24 can paint into this object or
  39. indeed perform any of its functions on the object. All changes are reflected
  40. immediately in Compo.
  41.  
  42. This means that an application can have other applications as 'tools'. Small
  43. 'applets' can be written to provide specific functions to a PCA application
  44. and they will be usable by any other PCA compliant application.
  45.  
  46. Imagine a simple application that does nothing else except display a
  47. sprite and conform to the PCA standard. Another application could provide
  48. paint tools, yet another could provide filters, another might provide
  49. warping tools - you get the picture I'm sure. From this range of applets you
  50. can construct the tool that you require to get the job done.
  51.  
  52. What's more, more than one remote applet can work on the same object at the
  53. same time and changes made in any one of these will be immediately reflected
  54. in all of them.
  55.  
  56. This is an awful lot better than OLE but there's still more.
  57.  
  58. Instead of each applet opening its own window we can use 'In-place' editing.
  59. This means that only the  Local application displays the document. When you
  60. click on a 'tool' entry in the Utilities menu the new tool's Toolbar opens
  61. over the Local application's window. All tools then work on the image in the
  62. Local's window.
  63.  
  64. Now you are really able to construct an application from a range of applets.
  65. All you will see is one window displaying the document.
  66.  
  67. Take this a little further and imagine a DTP package supporting the PCA
  68. standard. It could have a frame containing a graphic image and you could
  69. link this to PA24, Compo or any other PCA application, which could
  70. manipulate the image. The changes would be reflected immediately in the DTP
  71. window. However, if In-place editing is used, the Toolbars would appear in
  72. the DTP window and allow you to edit the graphic directly in the DTP window.
  73.   
  74. What we now have is a system whereby an application can have an infinite
  75. number of additional tools and all applications conforming to PCA can be
  76. used with and by all other PCA applications. An example of this could be an
  77. image in a DTP frame linked to Compo which used this image as a 'canvas' for
  78. a composite picture. From Compo one of the images in the composite picture
  79. could also be linked to ProArt24 and any changes would immediately be
  80. reflected in Compo and the DTP package.
  81.  
  82. Things may become clearer if you take a look at the example applications and
  83. documentation provided. The main document to read is 'ToTest'.
  84.  
  85.  
  86. A more technical explanation
  87. ============================
  88.  
  89.  
  90. There are two 'sides' to PCA support. Applications may support either or
  91. both as it suits them. 
  92.  
  93. Local
  94. -----
  95.  
  96. A Local application creates and maintains an area of shared memory (on the
  97. RiscPC this is most likely to be a dynamic area, older hardware must use RMA
  98. or something like the Dynamite memory manager). Objects in this area may be
  99. edited by any PCA 'remote' application which is running, provided that it
  100. knows about the type of object concerned. It is the local application's
  101. responsibility to create and maintain pointers to objects and to take the
  102. correct action when an object moves or changes size.
  103.  
  104. Remote 
  105. ------
  106.  
  107. A Remote application modifies an object in some way when requested to do so
  108. by a Local application. Remote applications can be small 'applets' or major
  109. programs in their own right. The PCA specification sets no limits on the
  110. changes which may be made to an object.
  111.  
  112. In practice, the two sides blur considerably. For example, it is possible
  113. for more than one 'Remote' task to work on the same object at the same time
  114. in which case the 'Remote' tasks must respond to some messages in a similar
  115. way to the 'Local' task.
  116.  
  117. In addition, an optional extension to the standard provides support for
  118. 'In-place' editing of objects directly in another application's window. 
  119.  
  120. Limitations, assumptions and philosophy 
  121. =======================================
  122.  
  123. The PCA standard requires the following:
  124.  
  125. Objects are stored in an area of memory available to all tasks. (eg. Dynamic
  126. areas). Beyond that the PCA is designed to be as transparent as possible to
  127. the memory management system used by a program. See below for some notes on
  128. memory management related issues.
  129.  
  130. Objects are either entirely paged into RAM during any PCA exchange, or a
  131. virtual memory system which is transparent to the program accessing memory
  132. is used (Eg. Clares Virtualise).
  133.  
  134. Objects are stored in a cross-program standard format for which there is a
  135. method of rendering readily available to other programmers. Examples are
  136. RISC OS Sprites, Drawfiles, ArtWorks files, Plain text etc.
  137.  
  138. If you are writing or have written a program which produces data objects
  139. that may be desirable for other programs to render, you should consider
  140. providing a rendering module (or some code) which other applications can use
  141. to display your object types. You should also consider placing the details
  142. (if not the rendering code itself) in the public domain.
  143.  
  144. No well written RISC OS application is an island. By supporting the PCA
  145. standard programs can take advantage of each other's good features and
  146. minimise their weaknesses while providing the user with a far richer and
  147. more productive working environment. 
  148.  
  149. Memory management issues 
  150. ========================
  151.  
  152. For backwards compatability programs that wish to use PCA on pre RiscPC
  153. hardware can fall back to using the RMA or something like the Dynamite
  154. memory manager. We do not however believe that Dynamite is the best solution
  155. for a PCA task on the RiscPC. This is because Dynamite uses one dynamic area
  156. to store all of its data rather than one dynamic area for each task. This
  157. practice means that, in the event of a PCA remote task going wrong and
  158. writing beyond the end of the object being edited, *all* tasks using
  159. Dynamite could crash rather than just the one local task in question. Also,
  160. Dynamite will not work with Virtualise which provides a PCA compatible
  161. virtual memory system.