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