2007

From Organic Design wiki
Revision as of 06:14, 29 December 2006 by Nad (talk | contribs) (State 1)

The peerix and peerd aspects of development have started to merge together significantly in the last part of 2006, lets note our high level development plans and requirements here so we can have a good development synthesis in place for the new year --Nad 06:20, 16 Dec 2006 (NZST)

Distributed content

The big focus initially for the peerd side of development in 2007 is to get io.c up to speed and integrated nodally. The result of this will be that the distributed content will be fully dynamic and cover all content, rather than being just the backups. We want this single distributed content solution to cover everything we're working on in the project, both peerix and peerd. We can probably don't need this new environment to maintain the apache/php/mediawiki based content or functionality.

Stage 1

The first stage of development for peerd is to get the current state of the application environment (recursive rectangles) to be part of the distributed content. each running peerd.c would be a local point of view into a single shared session of desktops.

Simplification of the build enviroment

The current buildroot enviroment is starting to become difficult to use as we add more of our custom requirements into the mix. GeeXboX has a simpler build system and most of the metadata for the software we would want to use. So I suggest perhaps designing a simpler buld system based on this.

No dependancy information will be handled at this level this is handled at the organisation level.

Division of target files

Files existing in the operating system image can be divided into two groups. Binaries are architecture specific and need to be compiled for the target architecture. POSIX files are those such as inittab, fstab and other configuration files that are similar across all architectures.

Self organising

A high priority once we have our distributed content in place is to ensure that each running peerd composing the network is as self-organising as possible so that we can increase the number of peers in the field without increasing the workload. To achieve this, each additional dependency added to our peerix/peerd system needs to be added in such a way that the ability to install/remove/upgrade/test can propagate amongst the other peers - ie we're never just adding new functionality, we're always adding the ability to integrate that new functionality.