io.cx is an idea for building computer programs that are easy for developers and ultimately users to customize.. a basic open development architecture might start the process rolling:

[edit] hub

the idea is simple: host a hub that coordinates software services.. make it easy to plug-in parts that can assemble to create a complete software service, (like a very personalized twexter)..

[edit] spokes

say we call the plug-in parts spokes since they connect to a central hub that coordinates their actions.. maybe there are two types of spoke: input and output

[edit] wheel

assembled, the hub and spokes would create a complete software service we could call a wheel

[edit] distributed web app

the hub could be a simple internet domain, like io.cx.. the spokes could be on a variety of servers and written in a variety of programming languages under a variety of licenses..

this wheel would sacrifice speed for flexibility.. if it even rolls, it might roll less like a ferrari and more like a mars rover.. at least premature optimization wouldn't be a problem:)

[edit] good idea?

is this a good idea? if you ask me, you are *not* asking an authority, but here are some reasons why the idea is cooking:

[edit] viaweb

paul graham's ViaWeb story sells the idea of the ASP serving web-based applications as a very good idea:

• steady improvements to software
• just in time delivery
• no versions to roll out, manage
• fast, global response to users
• users get what they need asap

the software service streams to customers, nagging them not with versions, installs and updates.. the software just works to allow users focus on using.

[edit] distributable?

obviously, ViaWeb was delivered from a single server, finely tuned to work with a specialized application.. could multiple, specialized micro-services on multiple servers be coordinated by a HUB to deliver a single useful service?

if so, there may be a few benefits:

[edit] customizing

different users may have variable uses for the wheel and might reassemble spokes to create a specialized version that does what they need it to do..

[edit] multilicense

maybe services provided from variable licensing restrictions could be put together, so end users could have more options.. better service

[edit] multilingual

spokes could be written in any language.. a simple spoke might prototyped in PYTHON, then, if necessary, optimized in C or LISP.

language independence may help specialists focus on making specific functions do very simple things and do them very well..

[edit] specialist

too many cooks spoil the soup..

the mythical man month says more programmers working on a problem can actually retard the delivery of a solution.. many programmers prefer working alone or in small groups..

working in groups, programmers are reportedly more productive when individuals own individual parts of code that coordinate with other parts to deliver a full service..

[edit] variations

while a programmer may own individual code, nothing could stop another programmer from delivering a similar service in a different way, in a different language, from a different server..

nor could anything stop another service provider from creating a new spoke that identifies and resolves a new problem to make a better wheel

[edit] more perfect

a process of competition may help the best solutions arise, with the end result being constantly improving cooperative services.

[edit] bad idea?

chances are good this a bad idea.. the list of reasons why the idea probably sucks is probably long and here's a start:

[edit] inefficient

program modules would not be able to talk to each other directly, they'd have to run back and forth to a hub

i don't know much about programming but do know i was shocked to learn FEDEX sends a package to nashville before sending it down the street..

NAPSTER may not have been as efficient as other P2P architectures, but did offer a centralized HUB enabling resources to be globally indexed and accessed..

[edit] bottleneck

chances seem good (or bad) that the HUB could get overwhelmed if there was high volume use..

high volume isn't an immediate priority.. maybe a simple hub that does one thing very well could handle increasing traffic?

[edit] mess

programming languages have better capacity to complete complex services when such are delivered within a single langauge

[edit] slow

depending on the application, users dislike slow performance.. this wouldn't work for photoshop.. but when publishing a wikipedia edit many may use, then users seem not to mind a little delay..

[edit] unreliable

if one spoke service was interrumpted, it might break the whole WHEEL..

with a zillion servers online, it might not be rocket science to build in some redundancy

[edit] naive

whoever is cooking this scheme is obviously naive

doh

[edit] similar ideas

it's likely that this idea has already been proposed or implemented somewhere.. please add to this list of similar systems:

• "distributed computing" SETI etc

[edit] better ideas

this info is on a wiki for a reason..

[edit] summary

a distributed application service founded on a hub, spoke, wheel architecture may not be optimal for finely tuned enterprise services, but may be worth a try when creating and developing new applications.. particularly to suit language preferences of users for a program like twexter