Data Structures

`Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.'

Fred Brooks

The acronym KISS is so true. It is for this reason that the data structures are easily the most important element of a good design. I also identify with the following quote:

``Somebody finds the problem, and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.'' -- Linus Torvalds

Well, I'll make the statement that developing good, robust, extensible, and simple data structures is the most difficult part of program design. Sure, programmers can code, but it's the the structure, the framework, that provides the foundation upon which you can build Babylon. For this reason, the data structures must be the most carefully designed portion of the software.

Anyhow, enough babel about structures ;)

I haven't quite decided how to copyright (or left for that matter!) the code. I'm going to thoroughly read the GPL and Apache licenses. From what I've seen of the Apache License, I am liking that. The GPL has a lot of snares that people seem to discuss a lot; I want to release this under a simple copyleft, I'll post it at some point in February.

Here are some preliminary structures:

Resource structure

The resource structure is used to define a loadable module. All loadable modules are considered a resource inside in the server. A resource registers itself as a child of some other resource. The lowest level resource is the Server. The module must declare what it is a primary child of when it's loaded.

Take for instance the display module, the sound module, and a the CODEC module.

The display module is a child of the server because it is a primitive resource. The sound module is a child of the server because it provides a low level interface as well. The CODEC module is a generic CODEC implementation which registers itself as a child of the server. However, the CODEC must provide the neccessary plugin interface for CODEC modules to interface with the rest of the system. Other low level modules must know of a CODEC's existance when inserted. The way that this is solved, is that the display and sound modules let the server know (when they're loaded) that they want to be notified when certain types of resources are inserted or removed, kind of like a card services of sort. Therfore, various resource types must be defined as rudimentary types at design time.

When a module loads, it passes a list of resources that it wants to be notified of status changes for. For instance, when a Gzip CODEC is loaded, the display server receives a message (data token) that has a source of the CODEC, a destination of the display, a type of NOTICE (or equivelent) and message specific information that tells the display what protocol the CODEC supports, it's CODEC id (like major/minor numbers in Unix), and any other specific information.

Message structure

It's late, this is the previous explanation, now it's a separate message and data structure

The data structure is used in this application as a multipurpose transient payload commander. It is used to send messages from one resource to another and send data to a resource from another resource. It is designed to allow synchronous or asynchronous delivery. If it is synchronous, the disposition simply has the SYNC flag set, without an actual delivery disposition. If the payload is to be delivered asynchronously, the ASYNC flags is set, and the disposition is set to one of: URG, NORM, LAZY, UNIMP. URG is urgent, please deliver data as soon as possible. NORM is deliver data in normal fashion. LAZY is to signify that if there are any NORM or URG disposition payloads, deliver them first. UNIMP is for unimportant. You would use UNIMP for a repaint message for a clock. If the system load is high, the server can just drop a repaint request for a clock on the desktop. This allows the server to implement anything from a TCP style protocol (with sequence number and checksum) to an ICMP style protocol (if there's bandwidth, relay this message, otherwise it's safe to drop) for managing data payloads. It allows the data payload to be prioritized, to weight the data flow in the system. A streaming video player might use URG on a sound pipeline to ensure good audio throughput, but use NORM on the video, because humans are less sensitive to slow framerates than stuttering audio.

Well, this is far from an exhaustive standard for the WHY server, but it's a start. Feel free to suggest enhancements via email.