Topic : TOS - das Betriebssystem Author : Version : tos.hyp (5. März 2013) Subject : Programmieren/Atari Nodes : 3001 Index Size : 93602 HCP-Version : 5 Compiled on : Atari @charset : atarist @lang : @default : Titel @help : @options : +g -i -s +x +zz -t4 @width : 70 View Ref-File15.10 System Services Protocol (SSP) TOS The purpose of the System Services protocol (SSP) is described in 'What is SSP?' Planning phaseIdea: Joakim Högberg Server Code and this Specification: Olaf Piesche CCurrently involved in specification, planning and future first implementations: Joakim Högberg (AtarICQ) Lonny Pursell (AtarIRC) Olaf Piesche(Smurf) Odd Skancke (TextView) Jo Even Skarstein (TaskBar) Ralph Lowinski (GuiTar) Rafal Kawecki (WAP-Browser, ArchView) Dan Ackermann (mICQ, AtarICQ-Overlay) Jan Krivanek (Atack) (aMail, aFTP) Erik Häll (MyMail) Martin Elsässer (ACSPro) Denis Huguet FalcAmp Emailed people (got the spec, waiting for reply): Joachim Fornallaz (GEMSetup) News UPDATED to V0.9: Nov. 17th, 2000 (see changes!) Dec. 9th, 4:39pm Martin Elsässer has announced interest to implement SSP in ACSPro. That means that all applications constructed with ACSPro could support basic SSP functionality from the start! Nov. 17th, 1:46pm AES message definitions added. Basically the protocol is ready. Just decided that the Server will feature 2 different debug modes. Because it will take a short while until we have implemented the protocol, it might be difficult to find out if the protocol is implemented correctly in terms of how SPAs and SRAs react to different messages. The standard debug mode will feature output and logging of incoming and sent messages and their parameters, but this doesn't show the reaction of SPAs and SRAs to different messages, if the protocol implementation in these applications is not finished. This will be solved by the Server providing an extended debug mode in which it can simulate both SRAs and SPAs, additionally to the logging. SPA programers: you'll get a dialog window in which you can send different service requests directly from the Server, as if another application requested a service (SRA simulation). SRA programmers: You'll have display in the same dialog window showing different requests coming in, and the Server will simulate being an SPA and sending back acknowledgement (SPA simulation) including simulation of Service Initialization and DRS delays. The debug modes will not be available in the first official release version, to keep the Server code small and efficient. About this spec Welcome to the online SSP specs ;) I want to ask everybody involved to tell me if you send the specs to somebody else, so that we can keep track of things and I can send updates to everybody. Target for V1.0 is an as complete as possible spec of Send File, Display Message, Send Message, Status Display, Context Popup, Compress File and Display Information Services. These are the services that will be primarily used by the currently involved applications. Changes to the spec will be listed on the 'SSP changes' page. Everybody involved is encouraged to come up with suggestions, improvement, criticism and anything else you can come up with. There are 2 reasons for not specifying SSP alone and releasing it then. One is, this way we have a broad base of applications supporting the protocol at release time already, which will increase the acceptance of it on the side of the users, and hence also on the side of developers. The other reason, just as, if not more important, is that this way not only ideas of one or two persons flow into the project, but of a variety of developers working on all different kinds of software. That'll make SSP more versatile and flexible and make it take several different points of view into account. Read SSP changes for everything else ;)