Difference between revisions of "Borgification"

From Organic Design wiki
m (needs tidyup)
Line 1: Line 1:
 
[[Category:Glossary]][[Category:Nodal Concepts]]
 
[[Category:Glossary]][[Category:Nodal Concepts]]
 +
{{cleanup}}
 
__NOTOC__
 
__NOTOC__
 
Borgification is the assimilation of established external resources and organisational aspects into the network's holistic system of organisation. It extends the unified network into other foreign "legacy" informational environments such as operating systems, language environments, document repositories, applications and organisations.
 
Borgification is the assimilation of established external resources and organisational aspects into the network's holistic system of organisation. It extends the unified network into other foreign "legacy" informational environments such as operating systems, language environments, document repositories, applications and organisations.
  
= Method =
+
== Method ==
 
A major aspect of borgification is the unification of external resources with the time domain (linear and cycles). This gives history, scheduling, analysis and budgeting to the resources and allows them to be incorporated into the network so that they can be managed by the network or using the [[peer]] interface.
 
A major aspect of borgification is the unification of external resources with the time domain (linear and cycles). This gives history, scheduling, analysis and budgeting to the resources and allows them to be incorporated into the network so that they can be managed by the network or using the [[peer]] interface.
  
Line 10: Line 11:
 
These features make it extremely easy to test out the network because it can be used alongside an existing solution and used as much or as little as desired without any concerns about migration.
 
These features make it extremely easy to test out the network because it can be used alongside an existing solution and used as much or as little as desired without any concerns about migration.
  
= Tools =
+
== Tools ==
 
*The Borg cube: Robust power and I/O box running peerix
 
*The Borg cube: Robust power and I/O box running peerix
  
= Borgifying XmlWiki =
+
== Borgifying XmlWiki ==
 
The reason for borgification is to avoid the painful process of migrating from one system to another, the [[Migration Plan]] concerns the various aspects of parsing and syncronising the various sources of project information we need to borgify, but this article is concerned with getting the peerd environment to the stage where it can accept this information. Borgifying XmlWiki allows it to continue working alongside the peer environment keeping content and changes syncronised. This will be done by first introducing the [[peerd]]-based [[Ultra Changes]] into the XmlWiki environment, and then [[flash-based-text-editor|WYSIWYG editing]] later.
 
The reason for borgification is to avoid the painful process of migrating from one system to another, the [[Migration Plan]] concerns the various aspects of parsing and syncronising the various sources of project information we need to borgify, but this article is concerned with getting the peerd environment to the stage where it can accept this information. Borgifying XmlWiki allows it to continue working alongside the peer environment keeping content and changes syncronised. This will be done by first introducing the [[peerd]]-based [[Ultra Changes]] into the XmlWiki environment, and then [[flash-based-text-editor|WYSIWYG editing]] later.
  
= Borgifying Standards =
+
== Borgifying Standards ==
 
This is the process of maintaining a class-instance relationship between a nodal context which specific implementation, or instance of an external standard (the class) such as [[w:POSIX|POSIX]]. This is similar to the way that the [[w:GNU|GNU]] Unix-like components maintain their conformance to the POSIX standard
 
This is the process of maintaining a class-instance relationship between a nodal context which specific implementation, or instance of an external standard (the class) such as [[w:POSIX|POSIX]]. This is similar to the way that the [[w:GNU|GNU]] Unix-like components maintain their conformance to the POSIX standard
  
= Borgifying Sources =
+
== Borgifying Sources ==
 
With the increasing popularity of open-source projects there is a huge resource of source code available to the community. Re-use of source code is very important to achieve our goals. Wherever possible we will use existing source trees to provide ''live'' sources. In this way as an associated project improves the quality of it's software, we benefit also.
 
With the increasing popularity of open-source projects there is a huge resource of source code available to the community. Re-use of source code is very important to achieve our goals. Wherever possible we will use existing source trees to provide ''live'' sources. In this way as an associated project improves the quality of it's software, we benefit also.
  
 
The process is a two way street, a dynamic, ongoing relationship exists between the peer environment and the external source tree. Changes made to sources by users within the peer interface are reflected in the external source tree too. The peer network integrates with external source trees the same way it integrates with other standard wiki's (of course the network user/group making the changes would need to be registered developers of the external project for this to work).
 
The process is a two way street, a dynamic, ongoing relationship exists between the peer environment and the external source tree. Changes made to sources by users within the peer interface are reflected in the external source tree too. The peer network integrates with external source trees the same way it integrates with other standard wiki's (of course the network user/group making the changes would need to be registered developers of the external project for this to work).
  
== Automated aquisition of sources ==
+
=== Automated aquisition of sources ===
 
Research points to a small number of commonly used technologies that may be used for managing source trees.  
 
Research points to a small number of commonly used technologies that may be used for managing source trees.  
  
Line 36: Line 37:
 
To flow back in the other direction, many projects post patches on their mailing lists for admins to commit, so ''diff'' and an email MTA is all that is required here.
 
To flow back in the other direction, many projects post patches on their mailing lists for admins to commit, so ''diff'' and an email MTA is all that is required here.
  
== Self containment ==
+
=== Self containment ===
 
The system's ability to aquire the source code that is used to build itself is a fundemental concept. In practice this means being able to obtain the source to an operating system kernel such as ''Linux''. Borgification of the Linux kernel tree is high on the list of priorities, in order to be able to implement the [[Peerix]] operating system.
 
The system's ability to aquire the source code that is used to build itself is a fundemental concept. In practice this means being able to obtain the source to an operating system kernel such as ''Linux''. Borgification of the Linux kernel tree is high on the list of priorities, in order to be able to implement the [[Peerix]] operating system.
  
= Applications =
+
== Applications ==
 
*[http://www.pricespy.co.nz Pricespy] style "scrapers"
 
*[http://www.pricespy.co.nz Pricespy] style "scrapers"
 
*Bank statement retrieval and parsing and transfers etc
 
*Bank statement retrieval and parsing and transfers etc

Revision as of 12:14, 29 May 2008

Broom icon.svg The content of this article requires cleaning up to meet OD's quality standards. Check the wiki best practices for guidelines on improving article and categorisation quality.

Borgification is the assimilation of established external resources and organisational aspects into the network's holistic system of organisation. It extends the unified network into other foreign "legacy" informational environments such as operating systems, language environments, document repositories, applications and organisations.

Method

A major aspect of borgification is the unification of external resources with the time domain (linear and cycles). This gives history, scheduling, analysis and budgeting to the resources and allows them to be incorporated into the network so that they can be managed by the network or using the peer interface.

The network connects with the foreign services on behalf of the network users, as far as they're concerned they don't leave their own local peer environment, so they can change the way it looks and works just like anything else. This allows the network to act as a load-balancing and distributed backup solution for the external service without the service having to change anything. The service or organisation being used in this way could also support the process and make it more efficient still, for instance by offering an API, or representing their information and services with a common protocol like RDF or RSS. Some services already offer this, such as flickr or Google maps, and web applications combining content behind the scenes from external services are called mashups.

These features make it extremely easy to test out the network because it can be used alongside an existing solution and used as much or as little as desired without any concerns about migration.

Tools

  • The Borg cube: Robust power and I/O box running peerix

Borgifying XmlWiki

The reason for borgification is to avoid the painful process of migrating from one system to another, the Migration Plan concerns the various aspects of parsing and syncronising the various sources of project information we need to borgify, but this article is concerned with getting the peerd environment to the stage where it can accept this information. Borgifying XmlWiki allows it to continue working alongside the peer environment keeping content and changes syncronised. This will be done by first introducing the peerd-based Ultra Changes into the XmlWiki environment, and then WYSIWYG editing later.

Borgifying Standards

This is the process of maintaining a class-instance relationship between a nodal context which specific implementation, or instance of an external standard (the class) such as POSIX. This is similar to the way that the GNU Unix-like components maintain their conformance to the POSIX standard

Borgifying Sources

With the increasing popularity of open-source projects there is a huge resource of source code available to the community. Re-use of source code is very important to achieve our goals. Wherever possible we will use existing source trees to provide live sources. In this way as an associated project improves the quality of it's software, we benefit also.

The process is a two way street, a dynamic, ongoing relationship exists between the peer environment and the external source tree. Changes made to sources by users within the peer interface are reflected in the external source tree too. The peer network integrates with external source trees the same way it integrates with other standard wiki's (of course the network user/group making the changes would need to be registered developers of the external project for this to work).

Automated aquisition of sources

Research points to a small number of commonly used technologies that may be used for managing source trees.

Many projects use versioning systems to keep track of code, just as we do with XML Wiki.

There are also a large number of projects that publish their code in tar balls without giving access to individual files. In both cases it is a simple matter to create a small script that will automate the process of aquiring and extracting the information we need. Many of the CVS-type systems provide an http read-only interface to the tree. In this case a simple curl is all that is needed. Others require the use of a client program to talk to the repository. For tar balls the standard GNU utilities such as tar, zcat and bzip are all that is required to deal with the archive.

To flow back in the other direction, many projects post patches on their mailing lists for admins to commit, so diff and an email MTA is all that is required here.

Self containment

The system's ability to aquire the source code that is used to build itself is a fundemental concept. In practice this means being able to obtain the source to an operating system kernel such as Linux. Borgification of the Linux kernel tree is high on the list of priorities, in order to be able to implement the Peerix operating system.

Applications

  • Pricespy style "scrapers"
  • Bank statement retrieval and parsing and transfers etc
  • Remote installation/upgrading over SSH or between peerd's
  • Network monitoring and analysis
  • Wikipedia and other wiki's (incl. other wiki-engines too)
  • Borgifying dependencies - project integration with SVN-like env's (some project's are gcc, linux kernel, SDL etc, see also Self Containment)
  • Multi OS/lang/hardware support (eg. iPod, XBox)
  • flickr
  • Google maps
  • Borgifying languages from their EBNF definitions for syntax highlighting etc