Jump to content


Photo

Uniform Server 4.0


  • Please log in to reply
22 replies to this topic

#21 Ric

Ric

    Project Manager

  • Admin
  • PipPipPipPipPip
  • 1,535 posts
  • Gender:Male
  • Location:Cambridge,UK
  • Interests:Electronics
    Internet in general
    Open source projects
  • SourceForge IDmpgcan
  • Wiki ID: Ric
  • Main OS: Windows XP

Posted 17 November 2007 - 06:01 PM

Not sure what to say! It’s the grain of rice doubled on a chessboard scenario.

The core components must remain easy to use, when overlaying any additional components either to enhance marketing ability or functionality must not impact on the core functionality.

I am not being negative, take Apache, self-contained, now run it on every OS you can think off. Tweak to make it OS compliant, this assumes there are no other programs installed on the machines that may or will conflict.

Add MySQL and perform the same tests and probably a few more tweaks only this time to both components.

So we are fully operational and add that new games program, well your servers worked fine yesterday! But now crash, you have only moved a few squares on that chessboard, suppose the grains of rice are keeping your feet warm.

What I am trying to say, every component you add needs to be fully tested, not only on the machine you use with its combination of software, but with a vast array of other machines and their mysterious components. Move up a few squares, now you are shoulders deep in rice.

The utopian ideal is to have a matrix of available server versions with corresponding programmes, allowing you to pick and mix to create your server installation. Not only a logistics nightmare but also a small problem of moving fifty squares on that chessboard, do the calculations, I am sure China would be happy to have that amount of rice. It’s that testability that is required, could take the ms route, put it in the public domain and make a fortune.

I think to put it into perspective; I saw one line of code that floored me, missed because it was not tested.

All the bets
Ric. :P

#22 tarka

tarka

    Junior Member

  • Member
  • Pip
  • 11 posts
  • Location:Norwich, Norfolk, UK
  • Main OS: Windows 2000

Posted 17 November 2007 - 07:17 PM

Hi Ric

I found your post illuminating and thought provoking. As a result it prompted the following. :P

For the purposes of illustration I will use the Car as an example. I guess that this process started life with the Ford Sierra seeing as how I know it as the Sierra principle. It is also referred to as “Features and Options”. Its objective was to allow every vehicle going down a production line to be unique, albeit a variant of the same model.

A specific model of car is sold today in many different variants, e.g. 3 engines, 3 transmissions, 3 body styles, 5 trims ..... You get the idea. If we take the numbers above 3 * 3 * 3 * 5, we finish up with 135 different end products from 14 major components. Admittedly, the numbers of variants can become massive very quickly. However, If we consider the relationship of three body styles and three engines, we have 9 interfaces, i.e. (9 different kits of parts to bolt any engine into any body shell) this is worst case, and if it happened in real life the designer would most probably be fired. If we repeat the process for the engine / transmission relationship we have a further 9 interfaces.

The solution to the car build issue was the structuring of the "Bill Of Materials" eg how the parts are grouped such that a specific vehicle could be represented by a specific list of part kits.

So where are we now. I believe that there is a parallel between the building of a car and a custom version of US. In building the code for US, the kits of parts = blocks of code. The difficultly lies in designing structured code that truly additive, such that it enables the total code to be amassed without gaps or overlaps. The process of mixing and matching the blocks of code can be contained in an appropriate form of conditional logic. I have seen a project run along these lines, where the source code was held in a modular form, and the final source file(s) were built using some custom code in Emacs.

I am not suggesting that this process is easy, as it requires the application of automotive technology to the generation of software. However, I am convinced that it is achievable, albeit, difficult.

It is worth remembering that the route to success is seldom easy.

Cheers

Tarka
=====================================
Future solutions have their roots in the past.



#23 Ric

Ric

    Project Manager

  • Admin
  • PipPipPipPipPip
  • 1,535 posts
  • Gender:Male
  • Location:Cambridge,UK
  • Interests:Electronics
    Internet in general
    Open source projects
  • SourceForge IDmpgcan
  • Wiki ID: Ric
  • Main OS: Windows XP

Posted 18 November 2007 - 09:00 AM

Hi Tarka
I absolutely agree “achievable, albeit, difficult” and “It is worth remembering that the route to success is seldom easy” that was the whole point of my little rant.

All the best
Ric :P




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users