WorldOS 0.2

---

From:    Lucas Gonze <lucas@gonze.com>
To:      xml-dist-app@w3.org
Subject: announce: WorldOS 0.2
Date:    Sat, 8 Jul 2000 15:01:08 -0400 (EDT)

---

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

---