Domicel is first and foremost a platform. It is a platform for writing Internet applications which, when viewed by the user, give the illusion of being part of his or her personal virtual domain. Most of the work that I have put into Domicel has gone into the platform - both designing and writing it.
However, everything that you see in your browser, including the Desktop itself, is an application. Far less thought and effort has gone into writing the applications (partly because the software engineer is constitutionally unsuited to writing applications). It is hoped that revealing Domicel to the public, even given the primitive state that it is in, will attract a few good application developers.
Anyone who is interested in becoming a Domicel application developer should contact David Boxenhorn here. If you decide that you are serious, you will be given a Host ID and a copy of the Domicel Server. You will also get David's commitment to personally help you with the problems that you will inevitably encounter.
To develop and run Domicel applications (under the currently-supported configuration) you must have installed, or available for use, on your server:
The currently available Domicel Hosts are hosted by eApps, under this program.
Developers will also probably want a debugger that can be used to debug both locally and remotely. The current developer is using Eclipse for this purpose.
The Domicel server is written in pure Java. As a result, the code runs without change under both Windows and Linux. (This is proven by the fact that current development is done on a PC running Windows XP, and deployed on an eApps server running Linux.) A zip file of most of the current applications can be downloaded here. These applications are provided both as examples, and to be used as the basis for similar applications. Feel free to copy the code and use it as you wish. Note, however, that much of the Desktop user interface code is provided by Treeview, and subject to its limitations.
Domicel Classes can be created from the Admin account of any host. In doing so, its Services must be specified. For user interface support, specify the Browser Service. All classes must explicitly specify the Base Domicel Service. (The reason for explicity specifying the base service is to make it possible to introduce new versions of it without breaking old objects.)
The
Domicel class specifies, among other things, the implementation class.
The implementation class is an ordinary Java class that implements the
Java interface com.domicel.util.DomicelInterface.
The
com.domicel.util
directory contains utilities which the developer is advised to use, but
are not mandatory. Among them is the class DomicelImplBase,
a class which simplifies the process of writing Domicel implementation
classes. Its decendents DomicelForwardMsgBase,
DomicelForwardUiBase,
and DomicelForwardAllBase are
used to write classes whose implementations are other Domicel classes.
The purpose of these classes is to create an object with a fixed ID,
which can be publicized, while enabling third-party implementations.
Such an approach is taken with the Domicel mailbox: the mailbox
provided by the DSP does nothing more than forward its messages to a
third party (in this case, the user's mailbox on the Dommail Host). The
object to which messages are forwarded can be changed by the end user
at any time, thus ensuring that the user can change mailbox
implementations without notifying applications which send mail.
You will notice that many of the objects which the DSP provides have forwarding addresses. Thus, any of these objects can be implemented by third parties. You are encouraged to do so!
All Domicel Hosts come with five built-in accounts: Admin, Srv, Cls, ClsAttr, and ClsSrv. The Admin account is for performing administrative functions of the Host. The other accounts are for storing Services, Classes, Class Attributes, and Class Services (i.e. the IDs of services which a class implements), all of which are ordinary Domicel objects which can be viewed, modified, created and deleted through the usual Domicel operations.
Any Host can be a DSP (Domicel Service Provider). There is no difference between a DSP and any other Host, except for the way in which it is used (i.e. to provide login services for a Domicel).
The Domicel security system is very elaborate. The reason for this is the integration of three conflicting goals:
The developer of the Domicel applications to date has encountered many bugs which turned out to be security problems, i.e. an application didn't have the access it needed, to some object, in order to function. This section should be learned well by all Domicel developers.
The access manager object can be found in
the My Access group. Its user interface is very
primitive, and you will notice that it has a forwarding ID, so it can
be improved upon by third parties. However its functionality cannot be
forwarded (it implements the DomicelForwardUiBase
class), which is as follows:
The end user can define any number of access groups, each of which have an ID and a name. Accounts are created with four access groups already defined:
| Group ID | Group Name | Description |
|---|---|---|
| 0 | Default | Every object belongs to this group |
| 1 | Me | All the objects in my Domicel belong to this group |
| 2 | Same Object | The object currently being accessed belongs to this group |
| 3 | Admin Access | All objects in the Admin account of the current Host belong to this group. |
The user can assign any number of members to any group. A member is identified by a Host ID, Account ID, and Object ID. These IDs can be the IDs of specific Hosts, Accounts, and Objects, or one of two special values: -1, which means "any" or -2 which means "this".
- Host = -1 means
- Any Host
- Acct = -1 means
- Any Account
- Obj = -1 means
- Any Object
- Host = -2 means
- The Host currently being accessed
- Acct = -2 means
- The Account currently being accessed
- Obj = -2 means
- The Object currently being accessed
The user can assign any number of Hosts to the group. When the user updates a Host, it gets sent the currently defined members of each of its groups.
The user can update a Host, which sends the Host each of the the groups, and the members of that group.
Thus, there is a two-step process by which groups are added to Hosts: First assign the Host to the group, then update the Host. The user interface should simply this process for the end user. The reason why it has to be a two step process under the hood, is to fulfill two constraints:
Thus, the information must be centralized for management purposes, but decentralized for operational purposes.
So far, we have told only half the story: Management of access groups. The other half of the story is management of object access.
When you view an object in the Desktop, you will see on the right-hand side of the window a link called, "Click for access rights". Clicking on that link (if you have access rights to do so) will show a table of all the groups which have access to that object, along with the following information: Level, Access Rights.
Access Rights can be any of the following:
None of these rights have intrinsic meaning, in fact you can create new access rights of your own. When a method is defined in a Service, one of its attributes is the access rights category it belongs to.
Level can be any integer greater than or equal to zero. Level refers to the level of indirection above which the stated access right applys. (Remember that all access rights are positive, i.e. they state that such an object does have access.) Most of the time you will use either Level=0 or Level=1. For example, the following access rights:
| Group ID | Level | Access Rights |
|---|---|---|
| 0 | 0 | V |
| 0 | 1 | VESLMCDA |
| 1 | 0 | VESLMCDA |
say that any object in the Domicel in which the current object resides has rights to do anything. Any other object has indirect rights to do anything (i.e. if they send a message to an object in the same Domicel, and that object accesses the current object). But they have direct rights only to view the current object.
The above implys that whenever an object is accessed, every object in the calling path must have access rights to the current object which agree with the access right defined for the current method, in order for access to be granted.
Clicking on "Manage Object Access" enables the end user to change the access rights of an object. The groups which have access rights to an object have no meaningunless those groups are also assigned to the object's Host. To see a Host's groups, and the groups' members, double-click on "Local Security Manager" under "My Access". Make sure that you click on the Local Security Manager of the Host in which you are interested!