Since I am not a real nerd, I may be misunderstanding. It sure seems like you are going to go up against google. I have been reading off and on that they want to do the same thing. Gmail is only the beginning.

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.

One possibility might be to see what, if anything, you can patent, and then don't tell anyone at slashdot about what you have done. Then you may be able to share financially in google's future for us all.

I didn't intend that comment to come out as negatively as it did. I am sure that you must have put a lot of effort into domicel. It's just that when I think about google's market cap, and the number of good engineers they have (plenty of Askenazim, too) I wonder if you can make a go of it. (Assuming that I understand correctly that they have the same goal as you do.)

Of course people said the same thing about them when they decided to take on Yahoo...

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.

hmm...maybe you can let the gnxp'ers invest enough to hire a good patent lawyer? Or maybe not. Maybe open source is the best. Maybe we can think about this from a natural selection pov.

Thanks, neandertal. I already have a patent (see here).

If I didn't have a patent already, it would now be void, since I have already publicized it.

Wow. Well good luck to you. The patent system is a real mess, from what I understand. It looks like you have wipo patents as well. It also appears broad enough to be valuable when google et al jump in, so good for you.

Since you are clearly David, and up against Goliaths, I would like to help however I can. Unfortunately, that amounts to just about nothing. What I look forward to is ideas from folks here about how to best disseminate this. It is not genes nor memes, but it will be fun to see how far it gets. I guess it would get out best virally, but you need some reason for people to want to use it. At this point, is there one?

From a pr point of view (although I am not a pr guy) I would emphasize the fact that you are one guy (named David) with a big idea...

but you need some reason for people to want to use it

Exactly. Right now, since there are no applications that are worth anything, the only thing I have to offer is cool technology. That's why I'm aiming at nerds.

Thanks for your offer to help. You can help by telling your nerdy friends about it.

The patent system is a real mess, from what I understand.

It is.

So how is this different from Java?

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...

So how is this different from Java?

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".

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

where you could have different applications running on different remote machines that are displayed on the same workstation

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.

It doesn't go through a central server, which your model seems to imply (the DSP) so that is one difference

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).

enables objects created by different organizations on different servers to behave as if they are in one virtual space

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

though open to the public, rather than a single distributed application

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.

David,

I glanced through some of the documentation quickly - will read more time permitting.

But I have a general question, what utility or value do you feel your system brings to the table. Or another way of putting it would be, what markets do you anticipate your system will sell into.

I can see it as a way to do global distribution of updates and roll out new applications in a hardware and OS independant way, but there are technologies out there that do that. What more do you bring to the mix? Aren't you just adding a layer on top of this to handle authentication - like MS Passport or similar??

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.

Can you give an example of an AJAX site?

Dave,

Google employs AJAX extensively...

Pat, thank you for your copious comments! I think you missed the point of what I am trying to do. Nothing wrong with that - it's my job to explain it so people will understand.

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.

David,

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? Do you need to "package" the app to make it Domicel aware, or add Domicil hooks to it? Or is there an Domicile SDK avilable that would allow someone to create Domicile aware apps? Or what do you mean by integrate?

David,

Or are you offering a Service Oriented Architecture (SOA) based on Representational State Transfer (REST) Web Services?

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

Any level. See here.

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

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.

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.

Pconroy: 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.

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?

Does this system support billing or auditing?

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.

Ummm...david, are you soliciting ap-builders?

Ummm...david, are you soliciting ap-builders?

That would be great! The platform is not ready for serious apps yet, but fun apps would work!

I'm starting to get it...but I haven't quite wrapped my little mind around it.

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?

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?

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.

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?

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!

90a697 639c391011