Warning this part of the documentation is still a
puzzle.
High Level Design
Orthogonal Aspect Separation
The implementation shall reflect the strict separation of aspects
(meta systems) by design.
Orthogonal means here, changes in one aspect will never affect
statements concerning any other aspect.
Orthogonal aspects in Askemos:
definitions DEFINITIONEN
The Askemos is a space of objects (see DEFINITIONEN)
so called places.
Those places send/receive two types of mesages (read and write).
For details see AskemosDVM.
Desired Features
From the task of the Askemos operating system as derived from the before
mentioned AskemosScope,
this summary of initial features was desired:
This section was one o the first pages in this wiki.
I haven't modified it since early 2000 or so.
Now I do, because a) I noticed that the owner of the page got lost
and I don't want more spam and b) I stumbled over a reference to
Henry G. Baker Critique of DIN Kernel Lisp definition version 1.2,
which I have not (yet) read, but which argues in favor of a lot
of features we included into BALL over those years.
So, here this pages content from 2000-2008:
- Root less object network model.
- Persistent data.
- Not data specific, XML optimized.
- Flexible name space management.
- Object autonomy.
- ACID transactions.
- Simple messaging concept.
- Any extension language feasible.
- Lightweight threads at my fingertip.
- The sheer concept of a dead lock is a bug altogether.
- Many network protocols supported.
- API for backing store adaptors supporting freenet, gnutella etc.
- Distributed Virtual Machine (DVM).
- A frame work for object to sustain at least 15 years.
- Something for document management as Perl is for tasks like system
administration. Would have to be sort of an application server,
but none could deliver the needed features.
- Few dependencies, small footprint.
NuNuDesign
german high level design requirements (for managers)