View source for Programming Context

This page describes the way I conceive systems to those helping me or I cooperate with.

.
== <br/>Approach ==

My background is not software development (I am more network software and internet architecture oriented). I have experience in an odd method inherited from learning developping in extending the QNX OS for a personal venture and network design experimentation.

* I want to understand the Linux/OS machine I use and the scripts necessary to execute what I want and I can send by '''intelligrams''' (cross network executable datagrams).
* The intelligram approach permits to work along an "'''ASAP'''" ("[application] as a protocol") approach and support very large "industrial" systems where customized hundred of similar structures can replicated and maintained in parallel on the same of different SDNs (Software Defined Network).

I work on windows (often DOS, I am an old one, since ASAP is windowing ignorant: a remote/networked batch) where I have my tools [I learned it helped spotting flaws more easily to work in two different contexts] in order to :
* build a database (excel) of the parameters I need for the different sites I micro-industrialize.
* develop in "rusty" C (I am an old one) program to general a systematic script/intelligram system.
* load/maintain a copy of the scripts on the remote Linux machine and cron/execute it to carry the tasks on many sites.

=== <br/>Experience ===

I managed this way several projects with up to 3000 similar sites. I therefore hate non-prompt relation with a remote machine. This progressively builds experience towards a rustic and robust networked use inter-applications system ('''netix''').

== <br/>Basic framework ==

This approach calls for prompt '''models''' of the scripts for the task in mind, and support (explanation) when a difficulty is met (for example when an application has its own prompt layer). 

==<br> Wiki centered project ==

Mail corresponds to direct one to one exchanges. Wiki is "mail 2.0": it introduces a second generation of exchange where the same text can be worked on and seen by many. The next generation ("mail 3.0") will permit several works on several federated versions of the same topic and be selected/compared by many.

Right now MediaWiki is the most appropriate working solution. Cybagora is dedicated to practical R&D in the mail 3.0 architectural line, within the Presentation Layer six framework.

However, this is '''NOT''' for now yet.