- From: Lucas Gonze <lucas@gonze.com>
- Date: Sat, 8 Jul 2000 15:01:08 -0400 (EDT)
- To: xml-dist-app@w3.org
- cc: eric@w3.org
I'd like to ask for opinions from the community on the design of the WorldOS protocol. I hope I won't waste your time, and will try to avoid any kind of PR. I will also fill in the matrix from www.w3.org/2000/29-protocol-matrix.html. wOS resembles XP, except that it is more modular. There are three levels: byte transport, a level that allows us to map messages to handlers, and derived application protocols. The byte transport level has two types: Type 1: (fixed length) WorldOS CRLF <numeric string>CRLF message body The numeric string is the number of bytes in the message body. It is a decimal number. Type 2: (variable length) WorldOS CRLF <termination string>CRLF message body CRLF <termination string>CRLF Any byte values are legal in the termination string. The next level of the protocol allows us to map messages to handlers. It is strictly an envelope. An example is: <?xml version="1.0" encoding="UTF-8"?> <msg> <protocol> <function>foo</function> <subclasses>fooBase</subclasses> </protocol> <funcdata>bar</funcdata> </msg> The purpose of this information is to support, in an OOP way, derived protocols. Unlike XML-RPC and SOAP, it says nothing about the messages themselves. At this level serialization is not applicable. All elements are named, instead of defined by position. This allows us to use polymorphism to extend the protocol. The subclasses element is an example. Implementations that support the subclasses element may use it to find alternate func handlers if the handler named in msg->protocol->function is not available. In practice this means that a function A derived from B can add elements to the contents of msg->funcdata. The related message would be: <?xml version="1.0" encoding="UTF-8"?> <msg> <protocol> <function>A</function> <subclasses>B</subclasses> </protocol> <funcdata> <element used by derived class A> <element used by base class B> </funcdata> </msg> Finally, there are derived application protocols. At this level things like message ids, request/response, etc. come into play. One such derived protocol is meant to provide for peer networking. At the protocol level peer networking is mainly different from http in that proxying is a fundamental operation. wOS does this by storing hop-specific data in roped-off areas of msg->funcdata. These areas are <msg> <funcdata> <push/> <pop/> </funcdata> </msg> The push element is for saving state before forwarding a message. The pop element is for restoring state after receiving a message reply. Only the top element in either stack is visible (a.k.a. in scope) at any hop. To implement this we use recursively defined stacks... a recursively defined stack local data a recursively defined stack ...where contained stacks may be encrypted. Ok, on to filling in the matrix. A lot of the issues it brings up should be left to derived application protocols - atomicity for example. Protocol: WorldOS Organization: WorldOS Corp. Architects: Lucas Gonze Status: deployed XML syntax ns: 0 schema: 0 DTD: 0 Facets: serialization - n/a extensibility - yes skinnyness - planned but not implemented yet. Support for multiple transports is fully implemented. protocol: yes. See documentation on stack routing for details. transactions: n/a except in application protocols remote procedure: yes business process: n/a except in application protocols security: planned but not implemented yet. Probably TLS. routing: yes Thanks for your time, and apologies for such a long post. - Lucas Gonze
Received on Saturday, 8 July 2000 15:07:05 UTC