Doblet Vision

Doblet Vision

Mark Hooijkaas, $Revision: 1.1.1.1 $, $Date: 2000/10/12 02:15:30 $

Introduction

In This document I try to explain the vision of a new type of Internet technology we are currently working on. I will first give a short overview of some history behind the doblet, for better understanding the motive behind a doblet. In the next section I will describe what a doblet is, what it's components are, and what it's environment might look like. After this basic terminology, I will sketch some scenarios of how doblets could be put to practical (or recreational) use.

Motivation

The motives behind Doblet technology come from two distinct current Internet technologies: For the first type of technology I feel that interactive internet applications (chat) has an enormous potential, comparable with how the WWW took over the Internet world in the late 90's. The problem with chat applications is that there are just way too many different applications, that all are totally incompatible. Basically, for each type of application (e.g. text chat, video chat, whiteboard, games, etc.) there are many programs that the user must download and install. Not only is this very user unfriendly (to a extent that users will not even try to install most of these programs), it also is a fundamental problem in forming buddy lists (online user communities), because these buddy lists tend to be fragmented over applications. The doblet technology tries to solve this by providing a framework in which totally different interactive applications can be deployed.

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.

Picture of two converging technologies
As can be seen in the picture above, the doblet technology tries to merge the strong points of web technology and of interactive (chat) applications. Web technology will be augmented with more powerfull communication mechanisms, and with a standard environment for developing, deploying downloading and managing closely interacting client and server objects. Chat technology will get a standardised framework which hides and standardises all technological details of distributed communication.

Doblet Overview

What is a doblet?
A Doblet is a cute name for a dob, which is short for "distributed object". Most users won't care for that information. Most programmers would probably like to see a bit more precise definition.

Users view

For most users a doblet should not be more than a url to connect to. In fact most of these url's will be invisible to the user, because a doblet will connect to new doblet url's behind the scenes, just like a homepage links to many new url's. A user should rarely type the url manually, but mostly go to bookmarked doblets, or "surf" from a directory of doblets (like yahoo is a directory of webpages), to the individual doblets. In fact a Doblet may automatically load new doblets as part of it self, just as a webpage loads frames and images as part of itself.

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.

Programmers view

A Doblet consists of a ServerDob and one or more ClientDobs. A ServerDob runs in a DobServer (or a Doblicator, since that has DobServer functionality). A ClientDob runs in a DobBrowser (or a Doblicator, since that is a beefed-up DobBrowser). The program code of the ServerDob, the ClientDob and some configuration parameters together form the DobletClass (I still need a better name for such a packaging of code (bean?)).

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:

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.

Scenarios

Comparison with existing technologies

A buddy list is a convenient way to see which people of a certain community (e.g. your personal friends or buddies) are currently online. Because of the large diversity of applications, some buddies will be online on icq, some will be online on pow wow, some will be online playing Quake, etc.