DOSPR

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.2//EN">
<chapter>
<title>Detailed design</title>
<sect1>
<title>System overview</title>
<sect2>
<title>Filesystem hierarchy</title>
<para>
The filesystem is highly inspired from the UNIX one, but taking in consideration
the user only needs to access his files, applications, volumes or shared files
most of the time. Consequently, the following directories are available at top
level: "Apps", "Data", "System" and "Volumes". The "System" directory could even
have been called ".System" to only let the advanced users access it via the
common interfaces.
</para>
<para>
It could even be considered that the place of an executable in the filesystem
hierarchy could determine its privileges; this can't be a security risk, since
when one gains access to the filesystem, then he has already access to the full
system.
</para>
<sect3>
<title>/Apps</title>
<para>
It contains a sub-directory per applications group. In this sub-directory one
man find the following directories:
</para>
<itemizedlist>
<listitem><para>Binaries: the applications binaries</para></listitem>
<listitem><para>Engines: the applications' engines binaries</para></listitem>
<listitem><para>Libraries: the shared libraries</para></listitem>
<listitem><para>System: the applications administration binaries</para></listitem>
<listitem><para>Sources: the applications source code (a sub-directory per package)</para></listitem>
</itemizedlist>
</sect3>
<sect3>
<title>/Data</title>
<para>
Shared data: documentation, hosted files, ...
</para>
</sect3>
<sect3>
<title>/System</title>
<para>
System hierarchy. Contains the following sub-directories:
</para>
<itemizedlist>
<listitem><para>Apps: system essential applications and libraries, containing a Apps/subdirectory like hierarchy.</para></listitem>
<listitem><para>Devices: equivalent to the /dev</para></listitem>
<listitem><para>Kernel: equivalent to the /proc on Linux</para></listitem>
<listitem><para>Sources: the associated source code (a sub-directory per entity)</para></listitem>
</itemizedlist>
</sect3>
<sect3>
<title>/Volumes</title>
<para>
Hard disks, CD-ROM and DVD-ROM drives, USB keys, etc, that get automatically
mounted. To gain read and write access on them, one should have the necessary
privileges though.
</para>
</sect3>
</sect2>
<sect2>
<title>Special files</title>
<sect3>
<title>Configuration files</title>
<para>
FIXME: think about a DTD for configuration files, with maybe a type enforcement
(boolean, integer, enum, string), a way to specify multiple lines in strings,
and a way to handle lists of values.
</para>
<para>
Configuration files contain variable names along with their values, nested
inside sections. Default variables and values can be set in the global section,
which name is "" (empty string). The global section is the default one. Comments
are allowed on their own lines.
</para>
<screen>
#this is a comment
#default section is global
variable=value
[section]
variable=value
[another section]
#another comment
variable=value
another variable=value
[]
#this is global section again
variable=value
</screen>
</sect3>
</sect2>
</sect1>
<sect1>
<title>Programming interfaces</title>
<!--
- use a table, head with prefix, describe function
- prefix actually is a namespace, it should not be an abbreviation, but then it would be a pain to develop in C with it; else we could think of tricks to implement namespaces in C in a way, like:
{
namespace_set("GToolkit");
gt_win = window_new();
namespace_set("AppEngine");
ae_win = window_new();
}
which could ease the implementation of shared libraries, though this is ugly and can be a pain sometimes...
- detail every data type
-->
<sect2>
<title>Essential classes</title>
<sect3>
<title>Buffers</title>
<para>
Prefix is "Buffer".
</para>
<programlisting>
new(): Buffer
new(Size size): Buffer
delete()
get_size(): Size
set_size(Size size): Bool
</programlisting>
</sect3>
<sect3>
<title>Config</title>
<para>
Prefix is "Config".
</para>
<programlisting>
new(): Config
delete()
load(File file): Bool
save(File file): Bool
get(String section, String name): String
set(String section, String name, Variable variable): Bool
</programlisting>
</sect3>
<sect3>
<title>Files</title>
<para>
Prefix is "File".
</para>
<programlisting>
new(): File
delete()
open(String filename, FileOpenMode mode): Bool
close()
is_end(): Bool
read(Buffer buffer): Size
write(Buffer buffer): Size
flush()
set_position(Offset offset)
set_position(Offset offset, FilePositionFrom)
</programlisting>
</sect3>
<sect3>
<title>Lists</title>
<para>
Prefix is "List".
</para>
<programlisting>
new(): List
new(ListType type): List
delete()
get_type(): ListType
set_type(ListType type)
</programlisting>
</sect3>
<sect3>
<title>Strings</title>
<para>
Prefix is "String".
</para>
<para>
A string can be stored in different encodings, possibly longer than the 7-bit
ascii, or 8-bit ascii extensions ones (eg UTF-8).
</para>
<para>
Strings are always properly terminated when manipulated using this interface.
</para>
<programlisting>
new(): String //creates an empty string
new(Buffer buffer): String //creates a string from `buffer` using
//the default encoding
new(Buffer buffer, StringEncoding encoding): String
//creates a string from `buffer` encoded
//as `encoding`
delete()
get_size(): Size //get string buffer size
set_size(Size size) //set string buffer size to `size`
get_length(): Size //get string length
set_length(Size size) //set string length to `size`
</programlisting>
</sect3>
<sect3>
<title>Variables</title>
<para>
Prefix is "Variable".
</para>
<para>
This type is used for data conversions.
</para>
<programlisting>
new(VariableType type, Buffer data): Variable
//creates a `type` variable from `data`
delete()
get(VariableType type): //get variable as `type`
set(VariableType type) //set default type to `type`
set(VariableType type, Buffer data) //set variable as `type` from `data`
</programlisting>
</sect3>
</sect2>
<sect2>
<title>Applications engines</title>
<para>
Prefix is "AppEngine".
</para>
<programlisting>
new(): AppEngine
delete()
</programlisting>
</sect2>
<sect2>
<title>Applications interfaces</title>
<para>
Prefix is "AppIface".
</para>
<programlisting>
new(): AppIface
delete()
</programlisting>
</sect2>
<sect2>
<title>Graphical toolkit</title>
<para>
Prefix is "G".
</para>
<sect3>
<title>Conception proposal</title>
<para>
A list of a possible implementation guidelines follows.
</para>
<itemizedlist>
<listitem><para>a GCanvas is a surface, containing GCanvasItems</para></listitem>
<listitem><para>a GCanvasItem is a graphical primitive</para></listitem>
<listitem><para>GCanvasItems can be grouped inside GCanvasGroups</para></listitem>
<listitem><para>a GWindow contains a GCanvas</para></listitem>
<listitem><para>a GCanvas is a GWidget</para></listitem>
<listitem><para>every GWidget is a GCanvas</para></listitem>
</itemizedlist>
<para>
Consequently, every graphical item on screen is a GCanvasItem, GWidgets are
groups of GCanvasItems, and can contain other GWidgets, possibly being
GCanvases. This is a big advantage for code reuse.
</para>
<para>
A problem is, it doesn't handle resizing properly as is.
</para>
</sect3>
<sect3>
<title>Widgets</title>
<sect4>
<title>Canvas</title>
<para>
Prefix is "Canvas".
</para>
<programlisting>
//FIXME functions applying to GCanvases, but not to GWidgets
</programlisting>
</sect4>
<sect4>
<title>CanvasItem</title>
<para>
Prefix is "CanvasItem".
</para>
<programlisting>
delete() //deletes properly, whichever the type
show() //shows item
hide() //hides item
</programlisting>
</sect4>
<sect4>
<title>Label</title>
<para>
Prefix is "Label".
</para>
<programlisting>
new(): GLabel
new(String string): GLabel
delete()
get_text(): String
set_text(String string)
</programlisting>
</sect4>
<sect4>
<title>Window</title>
<para>
Prefix is "Window".
</para>
<programlisting>
new(): GWindow
new(String title): GWindow
new(GWindowType type): GWindow
new(GWindowType type, String title): GWindow
delete()
get_type(): GWindowType
set_type(GWindowType type)
get_size(): Size
set_size(Size x, Size y)
</programlisting>
</sect4>
</sect3>
</sect2>
</sect1>
<sect1>
<title>Sub-systems interactions</title>
<sect2>
<title>Booting process</title>
<sect3>
<title>ukernel</title>
<para>
Bootable file containing:
<itemizedlist>
<listitem><para>
memory management code;
</para></listitem>
<listitem><para>
process handling code;
</para></listitem>
<listitem><para>
the plugin for the / filesystem;
</para></listitem>
</itemizedlist>
it then reads and launches the following AppServers off /System in sequence,
waiting until they each have their system call interface ready:
<itemizedlist>
<listitem><para>
VFS;
</para></listitem>
<listitem><para>
Init.
</para></listitem>
</itemizedlist>
</para>
</sect3>
<sect3>
<title>Init</title>
<para>
Maintains the system's session, just like users' session do. Shares the
necessary system and subsystems states with authorized users.
</para>
</sect3>
<sect3>
<title>Virtual file system</title>
<para>
Has plugins for the different necessary filesystems. Maps volumes to the
filesystem hierarchy if necessary. Connects to other VFS AppServers if
necessary. May run as multiple instances on a system, with different priviledges
("chroot" equivalent).
</para>
</sect3>
<sect3>
<title>Hardware daemon</title>
<para>
Has the list of mappings between hardware identifiers and drivers. Watches
after the various hardware buses and loads/unloads the drivers consequently.
</para>
</sect3>
</sect2>
<sect2>
<title>Development tools</title>
<sect3>
<title>Assembly</title>
<para>
The assembly utility, "as", and the disassembly one "disas", are to be based on
a library, "libas". It should provide the following distinct facilities:
<itemizedlist>
<listitem><para>
<emphasis>parsing</emphasis>, if possible on top of the parsing library;
</para></listitem>
<listitem><para>
<emphasis>file output</emphasis>, using a dynamic plug-in system for architecture and file format;
</para></listitem>
<listitem><para>
<emphasis>disassembly</emphasis>, if it actually requires any significant additional code at all.
</para></listitem>
</itemizedlist>
</para>
</sect3>
<sect3>
<title>C compiler</title>
<para>
The C compiler, "cc", is to be based on top of a library, "libcc". It should
parse C code on top of the parsing library if possible, and provide this
functionality to other programs. A C interpreter, and other development
assisting tools would also be desired on top of this library.
</para>
</sect3>
</sect2>
<sect2>
<title>Graphical system</title>
<sect3>
<title>Graphical server</title>
<para>
The server is to use a common API for hardware access, implementing directly the
necessary OpenGL layer calls. It serves the OpenGL interface as an AppServer,
plus functions to handle user interaction and whatnot.
</para>
<para>
Each window has its own OpenGL context, and is actually drawing into a texture
and not directly on the screen, except while running fullscreen.
</para>
<para>
The window manager is an optional plug-in, which would benefit from a common
library ("libGWM"), and hook some or all of the window handling functions.
</para>
</sect3>
<sect3>
<title>Graphical toolkit</title>
<para>
</para>
</sect3>
</sect2>
<sect2>
<title>User applications</title>
<sect3>
<title>Accessories</title>
<sect4>
<title>Text editor</title>
<para>
It should provide syntax highlighting, through dynamic plugins, built on top of
the existing parsing libraries.
</para>
</sect4>
</sect3>
<sect3>
<title>Communications</title>
<sect4>
<title>Instant messager</title>
<para>
Built on top of a series of plugins to connect to the different existing
networks protocols. It focuses on multipart conversations (private ones being
just 2 parties conversations), with audio/video support. It could interact with
the users' session managers to update lists of allowed clients to shared
applications (drawing program for whiteboard, etc).
</para>
</sect4>
<sect4>
<title>Web browser</title>
<para>
Built on top of the XML parsing library, using strict mode for XHTML if
possible, else tolerant mode to also parse HTML code to valid XHTML.
</para>
</sect4>
</sect3>
</sect2>
</sect1>
<!--
- APIs
* C library:
. str*() => string_*() and buffer_*()
. C classes => String?, Buffer?, SList, DList, Hash, Config, ...
- sessions
* sessions manager/init => itself a session? => can log on it and set it up?
* system sessions/engines (services)
* user sessions
- inter process communications
- login process
* one can even login on a system service as if would join an existing session, and the setup and monitoring interfaces appear (make this possible generally from a user's session, and you've got the control panel)
-->
</chapter>