The second type of technology (www) does not have this problem. Although there are many different webbrowsers (and webservers), these all interoperate, because they all speak the same language, roughly speaking HTTP and HTML (of course there are all kinds of minor incompatabilities, that are a headache for the webdeveloper, but these dont prevent the overall interoperability). Because of this a user only needs one browser program, to use the enormous diversity of the billions of web pages available. The problem with the WWW is that it in essence is a document retrieval system, not fundamentally designed for interactive applications. A user requests a page and gets the result presented. Many new extensions have improved this basically statically nature (HTML forms, server side scripting, cookies, DHTML, client side scripting, java applets, etc.) The problem is that this still is a patchwork of technologies, mostly aimed at augmenting the capabilities of a document once it is retrieved on the client side. What is not possible without some serious programming on both server side as client side, is to have intense interaction (dialogue) between client and server, without retrieving new pages at each action. Even if programmers are competent to this kind of development, such interactive objects are not as easy to deploy because on the server side special (non-http) servers might be needed in daemon mode or whatever. Compare this to the plug and play nature of deploying new webpages, by just placing them on the webserver, and you have an ambitious goal for easy deployment of user-friendly interactive distributed objects. This is what we hope that doblets can provide.
The program a user needs for using doblets will be called a DobBrowser. A DobBrowser is used to connect to doblets (indicated by an url), which run on a DobServer. The DobBrowser could be a standalone dob browser, but more likely it will be integrated with a web browser (either as a plug-in for an existing web browser, or as an integrated new browser (e.g based on the open source Netscape Mozilla browser code)). One form of integration can be the use of a doblet within a HTML page. Just as a web page can embed an applet object with special HTML tags, so can it also embed a doblet. Although there are technical differences, a user will not see much difference between the two.
One important difference is that one doblet can have multiple concurrent connections to DobBrowsers. Because this doblet is an active object, it can communicate with all DobBrowsers at own will (it does not need to wait for a page retrieval of a browser). In this way the Doblet is a basis for chat applications, connecting multiple simultaneous users (through the DobServer) which can then communicate in any way the doblet supports (e.g. text chat, playing a card game, or a dice game, conferencing with a whiteboard, etc.)
Besides the DobBrowser, which is not very different from a user perspective from an ordinary web browser, we also envision a more flexible user tool, called the Doblicator. The Doblicator is a DobBrowser with additional DobServer functionality. This means that an user can load new doblets in his Doblicator and start using those doblets with other users. For example if an user finds some neat Yathzee Doblet code on the internet, she just drops that Doblet in his doblicator, and invite some friends to play with her. In such a case no dedicated DobServer is needed, and users communicate directly with one another using their Doblicators and/or DobBrowser. This feature would greatly enhance the possibility for people to experiment with new doblets, try combining them in new ways, and even develop some doblet code themself, without any need of a big corporation hosting such services on dedicated DobServers.
The url of a doblet points to the ServerDob. It is very important to understand that this url does not point to the code needed for such a doblet, but to an actual running instance of that code. There can be many doblet instances on a ServerDob of the same DobletCode. The names ServerDob and Doblet will be used interexchangeably because of the one-to-one relation between the two. In general the term Doblet will be preferred, in order to avoid confusion between the terms DobServer and ServerDob (which I already mistyped several times). The term ServerDob will primarily be used in reference to ClientDob. To summarize some terminology:
When a user installs a new DobletClass on a DobServer, this code includes some information when and how to create new instances of this DobletClass. Several (partly overlapping) alternatives exist:
doblet://dob.chess.com/BeginnersLounge/ChessBoard42
Up till now we have spoken about program code without specifying what kind of language it is in. This has a good reason. We want to try to keep the Doblet technology both language as platform independent. The first prototypes are all coded in java, because this language is extremely well suited to distributed computing and dynamic downloading of code. However several scripting languages might provide quick and easy development of functionality, which we want to be able to provide. On the other side especially for high speed games, but possibly other applications as well (e.g. video conferencing), binary executables might be supported as well. For binary executables a signing mechanism should be supported for increased security. There might also be a platform selection mechanism, so that client code can be provided for different platforms. The client language should have good GUI capabilities, because it is primarily used as user interface to a doblet. A scripting language like Tcl/Tk comes to mind, but scripting languages like perl and Python might be extended with graphical capabilities as well.