2007

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)

• see also Organic Design 2007 which covers plans for developing the Organic Design Platform.

Communications

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, and any other arbitrary file structures or remote caches too.

The interface to managing this structure of caches can initially be a multilevel bullet list article in the wiki, so that it's effectively just an upgrade to the current wikid-based fileSync function. Each rule in the list needs to associate a source with a list of destinations. The sources and destinations can be articles, categories, files or directories. The ability to process the list (if a directory or category) and process the content after reading and before each write is necessary. The list may be something like this example:

• Source url/name, filter=/optional-list-filter/, when=/locatime-match/, poll=/optional-change/, sub=input-transform1
  • Dest1, when=/optional-own-cycle/, sub=output-transform1
  • Dest2, when=/optional-own-cycle/, sub=output-transform1

Interface

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. The main aim is to get widgets implemented so that the simple wiki-based interface to the distributed content can be moved into the network.

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.

• See Two pass assembly

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.