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.2 What is SSP? TOS SSP is an approach to make functionality of different applications useable throughout the whole system. All applications are targeted, although networking applications will probably benefit most quickly. SSP is a Client-Server architecture. The SSP-Server (background application) has globally registered applications providing different services (service providing applications or SPAs). Service Requesting Applications (SRAs) can use the SPA's services for their own documents. Example: . User opens popup by right clicking into an image in Smurf . User chooses 'System Services' in the popup and another popup . with all possible services opens (provided by the SSP-Server) . User chooses 'Send file' and another popup with registered Send File Service applications opens (provided by SSP-Server) . User chooses for example AtarICQ . Smurf sends Service Initialization Request (SIR) for Send File and chosen SPA (AtarICQ) to SSP-Server . nolink [SSP-Server]), if necessary, starts AtarICQ and sends Send File SIR along with request for list of possible recipients . AtarICQ sends list of online users to SSP-Server . nolink [SSP-Server]) opens popup with possible recipients . User chooses one . Server sends Service Use Request (SUR) for Send File service to SPA (aICQ) . aICQ opens connection to recipient and sends image file . aICQ confirms the Server with SPA Service Acknowledge (SPASA) . Server confirms Smurf with Server Service Acknowledge (SSA) Possible services and registered applications are held in different configuration files on the Server side. When new applications want to be registered, it can be done at the first communication between the SSP-Server and the application, or pre-use, by the application installer or config program. The first possibility is for convenience to the user, because simply copying and using a new version of a program would not corrupt the registration with the SSP-Server, since the application would register itself with the Server at startup. Registering with the SSP-Server consists of a short communication in which the program path and name of the SPA and the provided services are sent to the Server. The Server could runtime (when services are requested by the SRA) check for the existence of registered SPAs, which will prevent errors upon service initialization. What is the SSP-Server? The SSP-Server is an application running in the background that manages all communication between SRAs and SPAs. All services are hardwired into the Server. This system has been chosen for several reasons: . The Server can perform error checking, correction and prevention, which takes workload off the developers of implementing SPAs and SRAs . The Server can perform user interaction (choice of service, choice of SPA, user parameter input) without the SPAs and SRAs having to hassle with it. . Appearance of the user interactive parts (popups, dialogs for parameter input, etc.) is consistent . Hardwiring the services prevents messy implementation and introduction of new services . The Server can combine different services into one, for example Compress File Service and Send File or Upload File Service to Compress and Send or Compress and Upload, without the SRAs and the SPAs having to know about it. . The protocol can be extended in many cases (e.g. with global contacts, see 5.) without interfering with any previous implementations and specifications. The Server may install a cookie to indicate its presence. This might make it possible to have the Server run without menu_register, which would keep it more or less completely invisible to the user. This will prevent accidental termination of the Server (by [Control]-clicking on its desk-menu entry) and make it work more as an integral part of the system. The SPAs have to register with the Server. Currently, the best way to do this seems to be at 2 different points: a. At the SPA's first time installation b. At every startup of the SPA b is for convenience and reliability reasons. Sending a small registration information block to the Server at any SPA startup makes it possible, for example, to simply copy a new version of an SPA over an old one. If the new version supports new services, the Server will find out about this on the SPA's startup and can automatically update its configuration files, without the user having to mess with anything. The user will have the possibility to switch single SPAs for certain services on and off, for example for the Status Display Service (see sspServices.txt). Registration protocol still has to be specified.