DOSPR

Back to the revision list Download file Permalink

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

<title>Implementation process</title>

<sect1>

<title>Development policies</title>

<sect2>

<title>Communication</title>

<para>

FIXME

- decisions

- project modifications: APIs, documentations, teams, ...

- medias: IRC, mail, mailing-lists, web site, ...

</para>

</sect2>

<sect2>

<title>Code conventions</title>

<sect3>

<title>Design by contract</title>

<para>

Developping with contracts means that every component of the code has detailed

specifications of what is done, what is taken, and what is given back when using

it.

</para>

<para>

In practice, in addition to the components specifications, every function must

be written with the following comments block:

<listitem><para>PRE: the requirements for the function

to be working as expected, and for the data given as

input;</para></listitem>

<listitem><para>POST: what is done when the function

exits, and what is given back if so.</para></listitem>

</itemizedlist>

In many cases, and as recommended elsewhere in this document, one has to

implement components as a combination of many functions. As this part of the

code may suffer from significant changes, its design being let to the

appreciation of the implementer, it is tolerated that this information is added

as the implementer will find convenient. However, every interface with other

component must be documented this way.

</para>

<para>

Also keep in mind that it always help to maintain this information, and that to

pass a successful audit a component will have to be entirely documented this

way. Moreover, when used in debugging mode, any code should always assert the

contract.

</para>

</sect3>

<sect3>

<title>Code indentation</title>

<para>

Every single line of code must be properly indented. It generally means that

every language-level instruction will have to be kept on single lines, for both

clarity and the versions revision system.

</para>

<para>

Whenever possible the code must be indented with tabs, which size defaults to 8

characters wide. Code lines must not exceed 80 columns. Of course one can render

tabs at his own convenience while working on code, though it must be fully

readable on 80-columns wide terminals.

</para>

<para>

There should never be any blank character following the end of the meaning of a

line. Tabs should be use to substitute blank wherever possible.

</para>

</sect3>

<sect3>

<title>Naming conventions</title>

<para>

Variables, functions, globally every entity should have explicit names. They

must be expressed in English, without spelling errors. Names can be abbreviated

provided they don't lose meaning.

</para>

<para>

Whenever possible the context of a name should appear before the associated

action. For instance, prefer "student_age_get" to "get_student_age".

</para>

</sect3>

<sect3>

<title>Language-specific applications</title>

<sect4>

<para>

FIXME

</para>

<para>

Function names are lower case.

</para>

</sect3>

</sect2>

<sect2>

<title>Validation process</title>

<para>

Every project should be developped while taking care of this process:

</para>

<listitem><para>Audit</para></listitem>

<listitem><para>Optimize</para></listitem>

<listitem><para>Audit</para></listitem>

<listitem><para>Think about possible features</para></listitem>

<listitem><para>If globally accepted, add selected features</para></listitem>

<listitem><para>Audit</para></listitem>

</orderedlist>

<para>

The following versioning scheme would be used, to ease the development tracking of every project state coherently:

</para>

<table>

<title>Versioning policy</title>

<thead>

<row>

<entry>Version</entry>

<entry>Description</entry>

</row>

</thead>

<tbody>

<row>

<entry>When the project just begins. Say x equals 0 without any functionality, 1 for early usage and user input handling, and increments upon successive versions.</entry>

</row>

<row>

<entry>Where x increments when the project hits new milestones. First y equals 0, and then increments upon successive versions.</entry>

</row>

<row>

<entry>Stable and complete version is reached, without any additional feature. Just like above, y first equals 0, and then increments upon successive versions.</entry>

</row>

<row>

<entry>If there is a need for a new design of the stable version, x gets incremented every time, and then y upon successive revisions.</entry>

</row>

<row>

<entry>Then on, every set of new functionalities increases x (starting at 2), then y upon design reviews, and z upon successive revisions (both starting at 0)</entry>

</row>

</tbody>

</tgroup>

</table>

</sect2>

</sect1>

<sect1>

<title>Development tasks</title>

<para>

It seems reasonable, if not obvious, to determine independant tasks within the

huge work described before in this document. There follows a proposal.

</para>

<sect2>

<title>Global tasks</title>

<sect3>

<title>Communication</title>

<sect4>

<title>Project frontmatter</title>

<para>

The project main access is its web site, hosted at http://www.defora.org/ . Its

content management system is nearly finished, and will allow desiring members

to contribute to its maintainance. The rules for membership and privileged

access will be available when the portal is ready.

</para>

</sect4>

<sect4>

<title>Important announces and debates</title>

<para>

Though it has not been setup yet, one or more mailing-lists will be available.

Their use is dedicated to announces and discussions, that deserve to be read by

their subscribers. They will be archived on the project website. Please use the

IRC channel below, until a list has been setup.

</para>

</sect4>

<sect4>

<title>General discussions</title>

<para>

An IRC channel has been registered on the freenode network: #DeforaOS. This

channel is dedicated to discussions related to the DeforaOS system. The

preferred language is english, and the preferred charset is either ISO-8859-1

or ISO-8859-15. The rules are basically to be social, there won't be any

moderation unless complaints are filed to the project appropriate members, say

the mailing-list as a start.

</para>

</sect4>

</sect3>

<sect3>

<title>Programming interfaces</title>

<para>

The common APIs have to be decided and accepted by the project members, at the

appreciation of the project leader. They are then presented in this reference

paper.

</para>

</sect3>

</sect2>

<sect2>

<title>Cooperation tasks</title>

<sect3>

<title>Documentations</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>Low-level applications</title>

<sect3>

<title>Assembler</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>C compiler</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Micro-kernel</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>C library</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>System applications</title>

<sect3>

<title>General purpose services</title>

<para>

These applications only require their application engines. For an easy and safe

configuration, or monitoring, they may provide user interfaces though.

</para>

</sect3>

<sect3>

<title>Text mode toolkit</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>End-user applications</title>

<para>

Every application that fits on a desktop: file browser, web browser, mail and

news reader, messaging application, images viewer, audio and video viewer, and

optionaly games, etc.

</para>

</sect2>

<sect2>

<title>Graphics</title>

<sect3>

<title>Graphical server</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Graphical mode toolkit</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>Services</title>

<sect3>

<title>General purpose daemons</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Networking daemons</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>User interfaces</title>

<para>

The only essential part of these services is their application engines.

</para>

</sect3>

</sect2>

<sect2>

<title>POSIX environment</title>

<para>

At the moment it is not yet known if the system will be based on, or provide a

native POSIX development environment.

</para>

<para>

It may be possible to write an application engine providing the POSIX system

and library calls, on which the POSIX utilities would connect as usual

application interfaces. We could even imagine them with a graphical interface,

which would fallback as the regular UNIX commands if the graphical toolkit is

denied (using stdin, stdout and stderr as usual).

</para>

</sect2>

</sect1>

</chapter>