Tuesday, April 24, 2012

The application programming framework

I wrote this up a few years ago, thinking about how to implement a way to program complex systems.   Instead of writing programs like previous programming languages you create assembly lines of objects through which the data flows as messages.  This turns everything around.  Multit-hreading, multi-processor and cloud processing should be able to be introduced at the system level, without adding any complexity to the "programs" that people have already written.


The application programming framework is a general framework to manage the memory and messaging between objects.

Everything in the framework is an object.  From a simple number to the most complex protocol is an object.  TCP is an object, file is an object.

Let us say that one wanted to create a web server.

One would create a work unit object to contain everything.  A view, if you will.

Inside the view you create a TCP object, a stream to http object, and an http processor object.  Everything would be configured at this point.  Then connect the inputs and outputs between the objects together.

The starting and stopping actions of the work unit are defined.

Finally the objects would be started from the http processor to the stream to tcp object, and finally the tcp port would be started.

After everything is started then the tcp port accepts connections, this generates a connect message with a session Id that is sent to the stream to http object that allows it to set up a data structure in expectation of more to come.

Any data that comes in on session is sent to the stream to http object as a stream object with a session id embedded in it.  The http data object generated is associated with the session id as well.  The http data object is sent to the http processor.  The http processor queues up all the http requests.

When finished and the work unit is deactivated, the tcp object stops listening for new connections, the queue is flushed and all current work is finished, then the http processor is disabled, the stream to http object is deactivated, and finally the tcp object is deactivated.  After a timeout even if a work unit isn't finished, then everything is shut down anyway.

The key here is that it should be a very simple script to create, configure and connect these objects together and then to control their startup and shutdown behavior. With the proper base objects it should be easy to create a secure web service or an rss feed.

-- -- --

There are multiple levels. 

The memory.

The objects.

-- -- --

The first Object must be hand crafted, because there are no facilities to create objects until the object class exists.

Once the Object class is present then you can subclass from the Object to create new classes. 

The Object class is the root class.


I want to be able to easily swap out any subclass of the same type, so that you can easily change out a file for a tcp connection to make it easy to test processing from a file.

-- -- --


If you just declare to this point, then you will get the highest version of anything

Let us say that we have tcp.

inside that object path is version info.


It goes /major/minor/build

If you don't specify a version, then you get the highest version of the same major number you used when you built something.  You can specify just a major number, or a major and minor number or a complete path to a specific version. 

-- -- --

Installing versions.

"GrokThink" is the name for our company.  The URL to the GrokThink object repository is stored as a property in the GrokThink Object.

An interface is designed to check this repository for new versions and ask if the user wants to install them.

Build number changes are for internal use, to differentiate between versions for QA.  Minor number upgrades are controlled by QA, usually once a bug fix is done, then the build number is set to 0 and the build number is changed to incremented.  Typically these changes are minor bug fixes or a feature add that will not change the behavior of previous functionality.  The key here is that the fix or feature add should not change the behavior of objects previously used to build prior services or applications.

Major number changes are made for incompatible changes to an object. Often you will change the interface or fix a bug in such a way as to no longer work with older objects.  At this time the major number should be incremented and the minor and build numbers set to 0.

Development goes like this:
1. Developer gets a bug against a specific major version.
2. The bug report includes a new unit test to demo the bug.
3. Developer checks out the source, this increments the build number.
   This also locks the object so nobody else can work on it.
4. The Developer fixes the bug.
5. The Developer runs the unit tests against the object, adding in the new bug unit test.
6. Once all the tests pass, the Developer can check in the fix to the code system.
   A description of what was fixed should be attached.
7. This creates a diff from the old code, the new code and diff go into the system for another developer to double check.
8. The developer approves or disapproves the fix. The two developers negotiate a fix and finally the second developer approves the fix after the changes are made.
9. The final fixed release is sent to QA.
10.  QA approves the release and the release is put into the published area of the site.

11. The end users versions of the software can now download and install the new object.

The Development system comes with the software to perform all of these actions and publish to a public web server for your own company.  The company name is the name of the web server that the repository resides on. This will prevent any conflicts as time goes on between different companies.  There can be a redirect added to override the repository location if the website name where the repository resides changes in the future.

-- -- --

No comments:

Post a Comment