Domicel Q & A

Q:

In the example you describe where the user drops a TV object onto a spreadsheet object, how will the TV object know how to act? Where will the functionality be that determines that numbers need to be diplayed, even for something as simple as price?

As I'm picturing it, the TV object will have a price field and the Spreadsheet object will grab it. But what if the TV object is written with a "List Price" and "Sales Price?" How will the Spreadsheet object know about them, and understand that it should display them?

In other words, I see the interoperability as a major issue -- even though you're moving the work of software design to the software designers, they are still going to have to work together nearly ALL the time in order to make effective integration -- the authors of the spreadsheet program will have to interface with the authors of, well, every single object that wants to use the spreadsheet object, won't they?

A:

The spreadsheet will simply create a column for each attribute of the object. It doesn't need to know what those attributes mean to a sentient user.

The great thing about human-mediated ad-hoc integration (which is what I'm advocating) is that there's always a human around to make the connection!

Q:

Interesting, I have worked with hosted apps previously, but they usually had partitioned servers, or multiple server instances running on a single box.

OK, now I can see you might be on to something here :) LOL

Does this system support billing or auditing?

A:

Not automatically. But it's the right architecture for building those kinds of apps.

Security, History, and Sub/Pub, though, are part of the system.

Q:

So, if I'm reading this correctly, basically you are providing an architecture whereby an application vendor can write an interface to their custom app which will expose its methods via web services in a distributed environment?

These web services once exposed have awareness of each other due to the common architecture framework, and can each invoke each others methods, if they have appropriate access?

So that for instance if I were editing a document, I could invoke a spell checker, which would be supplied by a vendor web service and already configured to spell check my document. In a fashion reminiscent of the way Firefox allows you to write extensions to add custom search engines to your browser, only in this case the extensions could "talk" to each other as well, and not just the browser??

Correct me where I'm wrong.

A:

You got it!

But that's not the interesting part. What you described can already be done via Web Services, etc.

What Domicel adds is multi-multitenancy. Multitenancy refers to the ability of one application to support many users and keep track of each user's activities separately. Domicel enables many applications to do the same thing together, without explicit support from the programmer. All the programmer has to do is support a simple interface.

This interface, by the way, makes it easier to write large applications, because the same solution can be applied to different parts of the same application.

Q:

Do you need to "package" the app to make it Domicel aware, or add Domicel hooks to it? Or is there an Domicel SDK available that would allow someone to create Domicel aware apps?

A:

You buy the server. You write Java objects which implement a particular interface. These objects are the "front end" of your application - you can put anything under them.

Q:

So the key differentiator for your system is integration, and not distribution - is that correct.

So that begs the question, to what level are dispirite apps integrated?

A:

Any level. See here.

Q:

It's nice to see innovation but I wonder if you have considered performance sufficiently.

In retrospect it appears that the Altair led to the future. My first computer was in fact an Altair. Chuck Peddle "the father of the PC" (in his own words) did not base either the Commodore PET or the Radio Shack TRS-80 or the CPU of the Apple II (6502) on the Altair. As Stephen Jay Gould was so fond of pointing out, evolution is bushy. It only looks like a ladder in retrospect. This means that at this time there are likely to be many approaches to the next paradigm. The winner is likely to be the fastes not the most sophisticated. The Altair went nowhere because it had terrible performance and was very unreliable. The evidence of history suggests that the race will go to the swiftest.

No central point of failure is a 1980's concept. When I first taught networking peer-to-peer networking was the vision of the future. Everybody was going to have everything always and hardware weaknesses didn't matter. Of course that never worked. Ray Noorda got into networking from a background in fault tolerance. LANs abandonned the dream of no central point of failure to achieve higher performance with client server architecture. That architectural principal carried forward to the thin client on the Web.

Virtuality is also an old concept. When PC spreadsheets were young IBM struck back with virtual spreadsheets running on 360/370 hardware under the VM (Virtual Machine) OS. I ran speed tests at the time. Even a stinky 6502 based second generation PC running Visi-Calc was faster than a mainframe running ADRS on VM. A bit later the second generation of spreadsheets included two new offering Lotus 1-2-3 and MBA. MBA ran under the UC-p system OS. It had far more features than 1-2-3 but it was much slower. The race went to the swiftest.

Google is popular because Google is so fast. If you want investors to back a change in architecture show them how how fast your solution is not how many features it has.

Also the idea that users are interested in a decentralized architecture is contrary to the historical record. The IBM PC was not the best computer in 1981. I much preferred the Sirius 9000 but the public was attracted to the big name. Similarly today Microsoft enjoys continued success at least in part because it is big and has an overwhelming market presence.

Political conservatives hate big government. Liberals hate big business. There is something to be said for both attitudes. But voters are attracted big government and consumers like big central private enterprises.

What is your business model? How and when do you recoup your investment? Or is this another quasi-political statement technology like Linux? Linux users endure an inferior product so as to be able to make a political statement. So do Prius drivers. Is that your purpose?

The PC experience you wish to emulate is the result of centralization (Gates and Jobs) not decentralization.

BTW what's wrong with AJAX? My instinct is that a technology that improves the performance of current distributed applications will do well. The best AJAX using sites are now remarkably PC like.

I am not trying to do something, that has already been done, faster or better. So it's hard to explain. Rather like explaining the World Wide Web, before there was one. Can you imagine? Hey look! This page comes from another computer. And when you click on this underlined word you get another page! Big deal. It's only when you get some content that you can begin to appreciate it as a phenomenon.

Anyway, all those features that look so last millennium to you are not the point. The point is to create a system in which applications can be delivered as services (which is already being done, e.g. Salesforce.com) but in which they don't all live in their own silos, isolated from one another, but appear to coexist in the user's own workspace - i.e. the applications know that they can cooperate with each other, and the user can integrate applications ad hoc. That does not yet exist.

Performance is not an issue because I am not proposing to distribute applications. I am proposing to integrate applications that are already distributed.

My comparison with the Altair is not meant to be taken too literally. Yes, I know that the Altair was junk, and none of the following PCs were in its direct lineage. I use that comparison because at this stage Domicel is comparable to the Altair, both in being first, and in being too primitive for anyone but the most dedicated hobbyist. Naturally, though, I hope it will have a brighter future.

No central point of failure and virtuality are old concepts, it is true. But they are still important. I see them as key features of the system, but they are means to an end.

The business model is very simple: sell the server. (We can talk about pricing schemes separately. Email me if you want more details.) The selling point, before critical mass is reached, is the ease of integration which it gives the end user, and the developer. Though, when a critical mass of applications become part of the Domisphere, it will simply become mandatory, like the World Wide Web.

I am not really seeking to "emulate the PC" - I just use that line to try to get the user experience across. The key feature is the delivery of applications as services over the internet, and being able to integrate them ad-hoc. Companies like Citrix try to emulate the PC, which just means that your ordinary finite PC is not on your desk, but somewhere else.

I have nothing against AJAX, in fact, I love it, and use it! AJAX is a way of delivering a UI of a single application - it is orthogonal to Domicel.

Q:

Sounds like EJBs to me, though open to the public, rather than a single distributed application.

A:

Getting it to work with any number of applications, from any number of sources, with no central authority keeping order, is the trick. It's why the Internet worked, and Minitel didn't.

In other words, Domicel, like the Internet, passes the nuclear war test: those applications that survive will still be able to interact with each other.

The importance of this (on a day-to-day basis, at least) turns out to be not that old applications can survive the destruction of part of the network, but that new applications can be added to the network at will, without passing through a gatekeeper - which would inevitably be a technical and bureaucratic bottleneck.

Q:

Next closest thing I can think of is xwindows, where you could have different applications running on different remote machines that are displayed on the same workstation. It doesn't go through a central server, which your model seems to imply (the DSP) so that is one difference.

A:

What you describe is like the World Wide Web - where you can be using applications from many different servers at once. What Domicel adds is that when you do so, those applications "know" that they part of the same "virtual domain" and can work together.

The DSP is no more central to the system than your ISP is central to the Internet. It's just the point where you choose to enter the system (there can be any number of DSPs).

Q:

The part about hot linking data over the net is good in theory, but I don't even bother hotlinking the data in the same files on my computer as it slows things down to a snails pace. Seems like it would be even worse on the net...

A:

It is not about accessing functionality over the net. For that we already have lots of answers. We are doing it right now by using this website.

It is about enabling the mixing and matching of services provided by anyone, consumed by anybody, without having any control points.

It is about enabling this world, but where services, though provided one by one, appear to the user to all be part of his "PC".

Q: 

I think that people have had a similar idea for a number of years. Check answers.com for a good description of a network computer.

A:

The "network computer" has been in the air now for almost a decade. However, there has been no consensus as to what that actually is. My contribution is to come up with a system that works without any kind of centralization. It is the dream of Microsoft, Google, etc. to centralize the Internet on their own servers.

My solution is architecture-oriented. It is an object-oriented Web Service protocol (and, of course, the server that implements it) that enables objects created by different organizations on different servers to behave as if they are in one virtual space - without endangering security or mandating a central point of control.

Q:

This amounts to a user-interface layer on top of an RPC engine. Basically, there just aren't any vendors that build user interfaces that sit directly on top of an RPC engine. But it has been possibly for many years now. It is starting to become more efficient, and this is sorta what Microsoft Live is trying to do.

You may find that a lot of what you're trying to do has already been created, you just need to put it all together into a service.

Java has something called Java Remote Method Invoke, as well as CORBA support.

I had a similar idea once, one that would involve a distributed service framework, with services cryptographically signed by providers, but spread over the network, with a micropayment scheme to pay both the providers and people whose bandwidth is used.

A:

It is NOT a user interface layer. It is an object-oriented Web Service protocol (and, of course, the server that implements it) that enables objects created by different organizations on different servers to behave as if they are in one virtual space - without endangering security or mandating a central point of control.

Of course, in writing a suite of applications (such as they are) for the system, I've written a lot of general software, and created a lot of general infrastructure for doing things that applications have to do, user interface among them.