DOSPR

Back to the revision list Download file Permalink

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.2//EN">

<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>

<para>

It contains a sub-directory per applications group. In this sub-directory one

man find the following directories:

</para>

<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>

<para>

Shared data: documentation, hosted files, ...

</para>

</sect3>

<sect3>

<title>/System</title>

<para>

System hierarchy. Contains the following sub-directories:

</para>

<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>

#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>

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>

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>

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>

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>

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>

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>

new(): AppEngine

delete()

</programlisting>

</sect2>

<sect2>

<title>Applications interfaces</title>

<para>

Prefix is "AppIface".

</para>

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>

<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>

//FIXME functions applying to GCanvases, but not to GWidgets

</programlisting>

</sect4>

<sect4>

<title>CanvasItem</title>

<para>

Prefix is "CanvasItem".

</para>

delete() //deletes properly, whichever the type

show() //shows item

hide() //hides item

</programlisting>

</sect4>

<sect4>

<title>Label</title>

<para>

Prefix is "Label".

</para>

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>

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:

memory management code;

</para></listitem>

process handling code;

</para></listitem>

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:

VFS;

</para></listitem>

Init.

</para></listitem>

</itemizedlist>

</para>

</sect3>

<sect3>

<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:

<emphasis>parsing</emphasis>, if possible on top of the parsing library;

</para></listitem>

<emphasis>file output</emphasis>, using a dynamic plug-in system for architecture and file format;

</para></listitem>

<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>