Topic       : TOS - The Operating System
Author      : 
Version     : tos.hyp (December 19, 2008)
Subject     : Programmieren/Atari
Nodes       : 3010
Index Size  : 93790
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Title
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File13.10.6  General Rules                                             TOS

   . All fixed message parameters are sent in the AES message-buffer, 
     data and extended parameters are sent in a shared memory block.

   . There is no direct communication between SRA and SPA, the Server 
     handles all messages for purposes of error checking and extending 
     messages and parameters with Server-handled components (e.g. 
     providing GEM object structures for popups and similar)

   . SPAs should provide services with as litle output as possible. 
     For example when aICQ is started by the SSP-Server with a Send 
     File SIR, the contact list window should stay closed and only a 
     file transfer window be opened (maybe configurable)

   . Error-messages concerning protocol issues should be posted by the 
     SRA, so that the service use can be provided as completely as 
     possible on the SRA side without having to handle dialogs and 
     messages from the SPA. Timeouts on the SRAs side should depend on 
     the service. We will provide suggestions for error handling, 
     timeouts and other special cases in the final documentation. 
     Error-messages concerning performing the service should be posted 
     by the SPA (e.g. file transfer errors in aICQ).

   . The SPA is never to change data in the shared memory blocks 
     unless this is explicitly specified for the particular service! 
     Keep in mind it's shared, so every change the SPA does might 
     apply to the SRA as well. For the current services it is 
     absolutely necessary that the SPA does not write to the shared 
     memory blocks. Exceptions from this rule so far: Display 
     Information Service.

Why shared memory?

Using shared memory for the data and parameter transfer between SPA, 
Server and SRA has several reasons. There is an ongoing fight about 
whether to use globally allocated memory blocks (Mxalloc) or shared 
memory for data transfer. Reasons that speak for shared memory are the 
following:

   . Shared memory is generally considered 'cleaner' than global 
     memory blocks, and it's more or less the standard way to transfer 
     data in memory between applications in Un*x operating systems.

   . Using global memory blocks would mean that the SRA would have to 
     either hold all possibly transferrable data in global blocks (not 
     really an option), or, upon requesting a service, would have to 
     allocate a new global block of the size of the data, copy the 
     data to transfer there and free the memory block again after the 
     service was performed. Handling shared memory is easier, since it 
     only consists of an Fcreate and an Fcntl call.

   . Shared memory can be declared as read-only. I'm not sure if this 
     is currently implemented in MiNT, but the word goes that it will 
     be. That means, that there will be a general protection by the 
     operating system on the SRA's side against SPAs accidentally 
     writing into their memory blocks.

   . If we have an elegant mechanism like that which also works with 
     MiNT and MagiC, why not use it?