FIXME - decisions - project modifications: APIs, documentations, teams, ... - medias: IRC, mail, mailing-lists, web site, ... 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. In practice, in addition to the components specifications, every function must be written with the following comments block: PRE: the requirements for the function to be working as expected, and for the data given as input; POST: what is done when the function exits, and what is given back if so. 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. 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. 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. 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. 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. 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. Whenever possible the context of a name should appear before the associated action. For instance, prefer "student_age_get" to "get_student_age". FIXME Function names are lower case. Every project should be developped while taking care of this process: Make it just work Audit Optimize Audit Think about possible features If globally accepted, add selected features Audit The following versioning scheme would be used, to ease the development tracking of every project state coherently: Version Description 0.0.x 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. 0.x.y Where x increments when the project hits new milestones. First y equals 0, and then increments upon successive versions. 1.0.y Stable and complete version is reached, without any additional feature. Just like above, y first equals 0, and then increments upon successive versions. 1.x.y If there is a need for a new design of the stable version, x gets incremented every time, and then y upon successive revisions. x.y.z 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) It seems reasonable, if not obvious, to determine independant tasks within the huge work described before in this document. There follows a proposal. 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. 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. 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. 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. FIXME FIXME FIXME FIXME FIXME These applications only require their application engines. For an easy and safe configuration, or monitoring, they may provide user interfaces though. FIXME 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. FIXME FIXME FIXME FIXME The only essential part of these services is their application engines. At the moment it is not yet known if the system will be based on, or provide a native POSIX development environment. 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).