LLD

Low Level Design - Implementation Decisions

Architecture

Askemos Application Layer communicating persistant processes (the places of Askemos)

persistant storage (plugin frame) protocol: byzantine agreement (over HTTPS plugin) notations (opaque data, XML, MIME plugin frame) functions (Scheme, pattern matcher, XSLT, etc.) tree data model

RScheme Chicken (incomplete) ...

optional, recommented encryption layer (SSL/HTTPS)

optional anonymisation layer

Details

1. http://www.openspice.org/ seems interesting; came quite late, I'll see once I've got some free time again

2. The Askemos server is similar in structure to the "proposed" xml management system here (german) and transmorpher: http://transmorpher.inrialpes.fr/ .

3. The TUNES [[http://tunes.org/new/HLL/architecture.html|architecture]] provides further information of the internal structure.
4. CodingStyle How to make sure that it will not stink http://www.chc-3.com/pub/beautifulsoftware.htm

5. Why Scheme instead of Java, C, C++, Perl, Python...?

   Scheme pretty good as an abstract virtual machine (as opposed to a concrete and never will be ideal vm). It has been found feasible to implement a distributed virtual machine using a pure functional subset of Scheme for restartable calculations and synchronise assignement.

   Thanks to Richard Fateman for this article don't miss the LtU-article, where I found it. TODO remove the rubbish talk here instead of a consise sentense pointing to http://scala.epfl.ch/docu/rationale.html , http://www.rescomp.berkeley.edu/~hossman/cs263/paper.html (for the desires and downsides) http://www.italianacademy.columbia.edu/pdfs/lectures/eco_dream.pdf (for the background, why there are so many useless language wars) http://cm.bell-labs.com/cm/cs/who/wadler/steele-oopsla98.pdf (for introduction of the way to avoid the lock in) and LtU for all the know how.

6. XML modelling We are still looking for a XML parser and XSLT implementation, which could be easier reused or translated than rolling our own (from 1998) any further. Those evaluated implement something like the DOM? (as static data structure), which is the worst idea since adam eat the apple. (TODO evaluate chances to useXerces+Xalan from http://xml.apache.org/ ). Because a DOM? tree can not be created (as a single object) without side effect, the model simply does not meat the quality standards set for Askemos. This is actually a real drawback for DOM? based software. If there is a huge part of the tree, which should be reused in another tree, the whole part must be copied (thereby creating a redundancy and update problem) instead of sharing the structure. There is however hope, because we can provide a "virtual DOM?" consiting of several objects to provide the same information.

   Furthermore we need a language, which lets us manipulate complex data structures and XML directly, both manual and computational. This calls for a mixture of literal XML syntax '''and''' SXML, pattern matcher and functional transformers. (See also Gregory V. Wilson on the topic.) SQL is nice to have (though read operations must be restricted to side effect free subset of SQL; basically just SELECT? statements).

7. ByzantineAgreement (KommunikationsInfrastruktur, RPCisBrokenByDesign)
8. StorageAdaptor (the hierarchical ordering above protocol is accidental: storage can be at remote locations, in which case notations and protocols are required to convey the data)

9. Memory Access control happens on the language level. Richts management happens at the information level, - not at the data level. But anyway, Askemos might me prior art for upcoming things under DigitalRightsManagement

Note: Microsoft copies many of our ideas with singularity.