One of the things that always bugged me is the sneering of Electrical Engineers about what a shoddy discipline Software Engineering is. They complain about out quality control, our lack of good standards, our lack of mathematical rigor, etc. It can really get on my nerves. Well I say it's time to turn the tables. Let's prove just how superior software is to hardware and let's hit them where it will hurt the most: power!
For years hardware has dominated the creation, management, and distribution of power. I say, it's time to turn power over to us, the software people. Although I have not studied any Electrical Engineering I felt that the discipline should be masterable with a little hard-core research. Over the last several weeks I have been covertly studying power using MSN search and have divined its secret comings and goings. I am now ready to announce that a complete conversion to software based power is at hand.
The first secret of power is that power is made up of something called a "watt" which is delivered over a network of wires from something called a power plant. It's clear that the EE people like to name things, but what is a watt? It took some research, but it turns out that a watt is nothing more that a number of jewels (often misspelled joules for some reason) delivered during a second. So to get one "watt" of power you need to give a jewel in one second. To get two watts you must give two jewels in one second, etc. Despite extensive research I was unable to determine exactly which kinds of jewels are required. I feel it is probable that the exact kind does not matter.
So, the first step in building software is clear, create a very fast jewel delivery system that can be connected to a network of wires. From this basic outline, I was able to put together the POIP (Power Over IP) Socket Interface which uses IP tunneling to deliver jewels over the internet (delivery is not guaranteed). This paper discusses its functioning.
My natural inclination was to deliver power as XML over SOAP as this would be the cleanest. Unfortunately, this was not possible for a few reasons: first the delivery of jewels is apparently done in order to achieve work. In my experience it is not possible to actually do work using XML and SOAP so this pretty much excludes SOAP as a possibility. Second, the protocol must be very fast since the amount of power is directly a function of the number of jewels delivered, XML is too slow.
The next likely possibility was to use a faster and more direct protocol like DCOM or CORBA or RMI. The problem with these solutions is that the jewels delivered will be used for unspecified types of work. All of these systems require advanced knowledge of what work is needed.
My solution was to make the jewel payload Ruby code embedded in strings. Here is the final draft for a jewel:
This can be represented as "class Jewel end " which is just 17 characters (including null termination). This means that on a network with an MTU of 576 it would be possible to send 30 jewels in a single packet!
Some people have expressed concern that the ruby "Jewel" class has no direct function. Remember that in power distribution it's not the power provider's responsibility to determine what use the power will be put to. This is the beauty of using Ruby, the class can be altered, rewritten, or extended as the user sees fit. With Ruby it should be possible to achieve any arbitrary work (given enough power).
With the jewel defined, it is now possible to construct an arbitrary JewelFactory class which provides an almost infinite amount of power. JewelFactories could be in any Jewel supporting language including Perl but probably not Haskell because people who write code in Haskell are against me. Connections to a particular JewelFactory are by means of direct sockets as I will be describing in my upcoming RFC110-220.
The beauty of using pure sockets to connect to the JewelFactory is that it enables backwards compatibility to the existing power network which appears to rely on sockets A-L (which are not, naturally, defined in any RFCs I could locate). I have attached some diagrams I found that are supposed to describe these sockets, but as you can see they are completely useless (typical gear-head work). It's not even clear which port they use. As a result of the lack of proper socket documentation in the existing power network, the code to connect to the existing network will need to be developed on top of this specification.
There are two existing specifications worthy of note. First is the Power over Ethernet specification. This appears to be a vague attempt to put power on Ethernet Cat5 cables using some kind of side-band signal. This is clearly a sad plot by EE people to subvert our cool IP standards and use their totally lame power standards instead. It can't even pass over fiber networks for some inexplicable reason. Also, this is an OSI layer 1 protocol of some kind. That can't be right; power is really important and should probably have a much higher OSI number, maybe 10 or even 100. The other specification that is related is the IP over power line standard. This standard attempts to tunnel IP traffic in some way over the existing power network. This is the opposite of what my standard does so I oppose it.
This overview of the POIP Sockets system represents an amazing leap forward in power technology. If taken up by W3C it is very likely to completely revolutionize our computers. While some elements are left to the reader, the specific detailed implementation should require less effort than many currently emerging standards such as XForms and will provide nearly limitless benefits. Should POIP be adopted there is a bright future for all software and we can be "unplugged" from outdated 18th century power delivery systems. At the same time we can really stick it to those know-it-all EE nerds.
Power to the people!