Social networking, a sure-fire incubator for groupware, is all the rage these days. On the web, we have evolved chat into messengers, mailing lists into forums, images into photo galleries and video expose's. And on the development side, opensource software pulls in contributors to various projects from all over the world. One type of application for social netoworking on the web, online gaming, provides a very fertile ground for discussing analogues for groupware and without doubt, gaming developers will likely provide some deep insights into what must be done to bring features to the fore for other groupware applications. Like other intelligent creatures, we learn by playing. And within the context of social networking, applications that may be described as groupware are at the pinacle of this play.
In the online gaming sector which for fun and entertainment, utilizes some of the current web's most sosphisticated features to provide an interactive gaming experience, groupware will be the holy grail, bringing eden to the web. Certainly, some games on the web are solitary. These are no big deal. But those that are pioneering multi-client group participation are currently limited by what web technology will do for them. And Koala will remedy that.
The big trick with groupware is sharing. Sharing most particularly, hovers around specific information and processes and at the crux of this sharing is a very common data structure, the queue. Now some of you might say no, it's a database or its the server. But still, the database uses a queue to sequence operations, reads, writes, whatever. And the same is true of the server. There may be several queues involved and these in turn may be enveloped within other structures and processes, to include for example, security shields, in particular.
In present scenarios, databases provide their own security as do servers. But that's the present scenario. Groupware however is limited when the sharing mechanisms are limited to the database and server. In Koala, client to client communications allow a whole different context of sharing, one that largely bypasses both the server and the database. And that context must accomodate a definition of a secure group where sharing is possible with a mechanism of select privileges and exclusion of non-registered users. Yet client to cleint connectivity is obscure. In a client/server architecture the server is always a player and it knows about which clients are registered users, while also being capable of public privileges. In the current context, a server database defines the gamespace ( or workspace ) and users share the gamespace in a way that may be supplemented by messaging each other regarding their inputs to the game. In a client/client context, clients are not necessarily directly privy to who is and who is not a registered user. They have to be informed before a shared connectivity can be set up with privileges in place. Further, the gamespace or workspace is not centered at the server. Part of this space may reside on the server, or it may be completely client-side.
Certainly, a client can query the server to acknowledge another cleint's registration authenticity and security status, but this involves extra work. An alternate methodology is token passing and exchange. When one client makes a request or responds to another client's request, tokens are exchanged which define authentication and security. These tokens must be mutable. That is, to defeat hackers who would quickly capitalize upon volume traffic that involves a fixed token structure, the tokens should automatically modify their form in a way that is known to registered clients. No hacker can ever fixate on the form of the token and run repeated scripted attempts to break in to the group. Session IDs are open to such attacks, especially, when the number of users on a site is enormous. The odds in favor of the hacker's success increase with user volume. Mutable tokens eliminate this volume advantage and make the hacker's success rate fall off to for all practical purposes, zero. The required exchange of tokens ensures that the hacker can not capture a one-way token and use this to attempt to barter access. The requesting client will always be required to present their token first.
How a token's form is changed is algorithmic and the frequency or scheduling of the change might be tunable. With very low user volumes, token mutation is required less frequently. Higher user volumes would require more frequent changes. When a groupware session between two clients overlaps the event of a token mutation, two methods may be used to update the clients, server polling of the clients or ... if the clients discover they are being denied inclusion, they can request a new token from the server. Keep in mind however, that one client has the right and the capacity to specifically deny another client. This is a special form of denial in which the denied client will have enough information to know that it does not need to update it's token.
Much still needs to be said about how Koala and its capacity for cleint/server role reversals impacts groupware and it is not beyond reason, that the traditional HTTP/HTML vehicle for information exchange may not only see alterations, but be supplemented by other vehicles and methods for exchange. But that's meat for another post.