If you are new to using a wiki, you might want to visit visit the wiki welcome page, otherwise you can just jump right in! There is after all a preview button, before you commit, so you can see exactly how your contribution will look.

<-- add a page of your own here, or contribute to another! -->

• Priorities: The most important consideration in the design of the framework is that is must work for all Java runtime environments, 1.2 and higher. This means, as tempting as some of the new features may be, there is simply too large an installed base to make it practical. That said, there has also been no really cool feature that we could not successfully recreate, using plain-old Java2. However, this does not mean that your applications are in any way restricted. For example, while all devices from mobile phones to desktop workstations can work together, all the latest and greatest features, like Swing for example, can be used, as long as you are sure all the receiving devices can support them.

• Features: One of the most important features of the framework is that applications do not have to be structured around it. This is quite unique amongst distributed frameworks. This makes it extremely to incorporate the framework into large existing applications. As we like to say; you don't design your applications around cajo, it simply drops-in! Straightforward object oriented design is all that is required. Its two main strengths are in the ease in which it allows Virtual Machines to join together dynamically to create a seamles virtual computer, and for its ability to remote rich user interfaces between them simply.

• Limitations: Being RMI based, cajo only works between Java applications. For some applications this can entail a significant porting effort. This is offset however, by the magic of mobile code. Being able to send an object to another Virtual Machine, including its class definitions, is a wondrously powerful feature that can only be provided by using Java.

• Performance: Since cajo is a small efficient layer built atop RMI, its performance is no better, or worse, than other Java technologies like Jini or EJB. While it entails a little more overhead than using basic sockets, the power and transparency the protocol provides are well worth the cost, and would ultimately have to be recreated manually to provide this much functionality.

• Persistence: The primary storage mechanism used in the cajo project is the zedmob. It is a contraction of the words Zipped and Marshalled Object. It allows remote references, and even remotely loaded objects to be saved to disc, or passed to other remote Virtual Machines. A zedmob is persistent in that its existence is entirely independent of the lifetime of the Virtual Machine using it.

• Scalability: The scalability of the framework comes in two forms; sometimes called static, and dynamic. Static scalability means a single application can simply migrate its objects between multiple Virtual Machines, to accomodate increased load or reliability concerns. Dynamic scalability means objects can join together to create emergent functionality. This second technology is very exciting, and still in its infancy.

• Security: There are many facets to security. For server reliability, hosting of proxy objects invites the possibility of a denial of service attack. A proxy object could require more resources than a host could provide, potentially hobbling the Virtual Machine. Security in communication however, can be provided in several ways. The communication can be done over SSL, but the overhead must be taken into consideration. There is however one way to encrypt rel="nofollow" sensitive objects, both individually, and separately. This can be both significantly faster, and even more secure.

• Comparisons:

  Note: Please do not regard these comparisons as denigrating any of the fine frameworks outlined below. It is just that the cajo project can perform all of their functionality, and even much more, very simply. If it could not do all this, it would not be worth developing the project in the first place. The tone of the comparisons is of the form: "Here is what that framework does in a nutshell, and here is why cajo is more flexible".

Serving as a giant global chalkboard; here all community members can feel free to post ideas, suggestions, comments, questions, and tips.