INSTANT COLLABORATION

Developing a Framework to Support New Patterns of Team-Cooperation

Alexander Schatten, David P

olz and Matthias Epheser

Institute of Software Technology and Interactive Systems , Vienna University of Technology, Favoritenstr. 9-11, Vienna, Austria

Keywords:

Instant collaboration, instant messaging, resource exchange, team collaboration.

Abstract:

Communication and collaboration is supported by a multitude of different (client) applications and backend

systems. At the same time, new patterns of collaboration between knowledge workers arise: people want

to communicate in-time, share resources, keep track of their issues and yet do not want to be unnecessarily

disturbed in their concentration. We analyse several systems and approaches to support team-collaboration

and ﬁnally introduce our understanding of “instant collaboration”. In our research we support ﬁrst patterns

with a middleware and client-side prototype. The system is built upon proven systems for (instant) messaging,

communication and repositories, and suggest a system that allows support for new work-patterns, yet integrates

seamlessly into existing IT and workgroup infrastructure and company policies.

1 MOTIVATION AND

INTRODUCTION

Knowledge workers want to communicate, they want

to share ﬁles, and they want to keep track of their

work. There are various tools and platforms avail-

able today that support many aspects of cooperation.

Yet we believe that most systems currently available

(commercial or open source) show signiﬁcant weak-

nesses in terms of instant collaboration, meaning the

rather ad-hoc forming of workgroups and supporting

their resource-sharing patterns. We will analyse these

issues in more depth in the next section.

We started developing a new framework for in-

stant collaboration, named JMellow which is part of

the larger Peer Group research effort. JMellow was

created as a research project, because there we see

the need for an easy-to-set-up platform that allows

instant communication and particularly resource ex-

change, annotation, discussion and versioning. JMel-

low is based on available and proven open-protocols

and open source systems (like instant messaging solu-

tions and repositories/content management systems).

Yet we notice a resistance against installing new

tools or introducing new protocols and proprietary

systems: resistance to new tools typically comes ei-

ther from management (in a corporate environment),

from system administration (who has to install, main-

tain and integrate these new tools) or from the poten-

tial users themselves. Already Grudin pointed out,

there should not be “a disparity between who does

the work and who gets the beneﬁt” (Grudin, 1988).

Thus, it should integrate in existing user databases

and content management systems (to please system

administration), be easy to use and easy to adminis-

trate. Moreover it should use (if possible) the client

applications people already use and only extend them

where required.

Eventually, traceability of work should be possi-

ble. Also, security issues and other policies (in the

corporate environment)—typically associated with

instant messaging (peer to peer) systems (Bhagyavati,

2005)—have to be addressed with our approach. This

is hopefully the foundation to encourage management

to consider instant collaboration tools as a next step in

enhancing the efﬁciency of their knowledge workers.

JMellow can be seen more as an instant collabora-

tion middleware than a speciﬁc client-based system.

Of course, we also developed client(s) in this project,

but the system can be easily embedded in existing in-

frastructure. As knowledge workers should have ac-

cess to the ﬁles of their workgroup everywhere and

Schatten A., Pölz D. and Epheser M. (2007).

INSTANT COLLABORATION - Developing a Framework to Support New Patterns of Team-Cooperation.

In Proceedings of the Third International Conference on Web Information Systems and Technologies - Society, e-Business and e-Gover nment /

e-Learning, pages 21-28

DOI: 10.5220/0001268300210028

 SciTePress

should be able to communicate with their workgroup

members, we have chosen to make the web client the

ﬁrst client implementation. Others are following. Of

course, JMellow can then be a simple ﬁle-sharing and

instant messaging application. Workgroup-related

performance metrics can be gained from the data that

is exchanged over the JMellow platform. Hidden

work ﬂows can be found, communication structures

be made obvious and project activities be measured.

This paper is structured as follows: section 2 will

outline some instant collaboration scenarios in detail,

whereas section 3 explains our JMellow infrastructure

in more detail. In section 4 we describe related work

in this ﬁeld. Section 5 gives a more in-depth descrip-

tion of the system architecture. Finally in section 6

we give conclusions and outlook for future research

work.

2 INSTANT COLLABORATION

A broad variety of applications are available on the

market, or as open source software projects that ad-

dress cooperation and communication. Mandviwalla

et al. (Mandviwalla and Olfman, 1994) describe vari-

ous needs and requirements of groups, and emphasise

in detail, that different groups and collaboration sce-

narios have different requirements and it is impossible

to deliver a generic groupware application that works

out for everybody. Open design and customisation

is necessary to support a broad range of applications.

Thus, we see openness as a foundation of our project

architecture, as will be described later on.

Moreover, in our research work, we focus on what

we call instant collaboration, which imposes new

collaboration patterns that are not well supported by

available software (see section 4). Daily work in dis-

tributed teams, show that beside communication, the

most important feature is a solid way to exchange re-

sources. Typical scenarios are sending ﬁles via email

or instant messaging clients. These approaches have

the disadvantage to be rather intrusive, as the work-

ﬂow of the colleague is most likely being interrupted

by this procedure. Moreover, resources are exchanged

on a person-to-person level; meaning that signiﬁcant

bandwidth is wasted, if (as it is often done) many

ﬁles are “broadcasted” to a larger community of co-

workers, while many are probably not interested in

this information, or not at this very moment interested

in the information.

Additional issues come up when documents are

changed and sent back to the originator or to other

persons. In a short time, documents run out of syn-

cronisation. Other ways to share such resources typ-

ically are shared-ﬁle systems, or even better CVS or

SVN repositories or other web-based ﬁle repositories

like BSCW (BSCW, 2003). These systems allow a

controlled storage of shared information, some also

versioning. Hence such system can provide valuable

help for group cooperation. However, some other dis-

advantages persist: to access these repositories, typi-

cally speciﬁc client software is needed or browser up-

loads have to be done. But more important, the repos-

itory interaction is not connected to communication

and collaboration activities.

We believe, that instant collaboration means com-

munication and closely-connected other activities like

ﬁle-sharing, annotation, access to other information

systems, probably project management functionality

and the like. Closely-connected means: ideally in the

same client software, and with a usability that does

encourage also less skilled users. Hence we focus

at the ﬁrst step on integration of communication (in-

stant messaging) with ﬁle/resource-sharing, version-

ing and annotation. Further steps are outlined in

section 6. But our concept is rather a communica-

tion/collaboration integration project, as we explic-

itly do not reinvent the wheel. So systems like SVN,

JSR 170 repositories, content management systems

or instant messaging middleware (Jabber, XMPP) are

used as a basis and are integrated to support users in

working with those valuable tools in a more produc-

tive way.

3 INSTANT COLLABORATION

WITH JMELLOW AND

INTEGRATION OF AVAILABLE

SERVICES

With JMellow, we want to demonstrate the feasibility

of our instant collaboration concepts (ﬁg. 1 shows a

screenshot of the Open Laszlo/Flash client prototype).

JMellow is platform-indepentent and will be provided

under Apache open source licence (Apache Licence,

2006). Instant collaboration with JMellow is very

straightforward. The user sees his or her colleagues

ordered in groups in the JMellow client. As JMel-

low is primarily designed for usage within a closed

infrastructure (Intranet), typically the user and group

information is provided by the middleware (database).

For our prototypical implementation, we use the Java-

based Wildﬁre server (Wildﬁre Server, 2006). User

and group information can be provided either from the

Jabber-Server directly, or via an LDAP server. This is

particularly handy in a corporate environment.

The closed-group (intranet) infrastructure ap-

WEBIST 2007 - International Conference on Web Information Systems and Technologies

Figure 1: Screenshot of the Flash (Open Laszlo) JMellow client. Contact list and documents are shared. In two chat windows

personal and group chats are held. The Flash client even can preview certain types of documents (like the graphics in that

case).

proach is also beneﬁcial in addressing issues with IMs

on the corporate desktop (Bhagyavati, 2005) (secu-

rity, policies. . . ). Usage as “open internet collabora-

tion platform” is not the target audience.

The consequence is that new colleagues immedi-

ately have a ﬁlled group/user list including contact in-

formation. This list of users can be used to chat via

XMPP protocol (Jabber). It is noteworthy here, that

the group/user structure also implicitly controls ac-

cess control and visibility: i.e., if a user wants to chat

with a person, she selects this person; if she wants to

chat with a group she selects the group and automati-

cally a group, chat is initiated. If a resource is shared

with a group, implicitly all group members have ac-

cess to this resource as long as they are assigned to

this group.

Using JMellow for resource management, it is

avoided that large chunks of information are dis-

tributed via email, and the like. If a user wants

to share—say, an Ofﬁce document—he “drag-and-

drops” it on the person or group. This document is

then sent to the JMellow server (which is from a tech-

nical point of view a Jabber client) and stored in a

proven repository. We experimented with a JCR-170

repository (Jackrabbit) (Nuescheler, 2006; Jackrab-

bit Content Repository, 2006), but currently use the

Daisy (Daisy CMS, 2006) content management sys-

tem.

This is an important strategy, as we do not want to

implement new systems where proven solutions are

available. The strategy is rather to connect proven

systems and enable their usage in instant collabora-

tion setups.

To conclude the advantages in terms of collabora-

tion on resources:

• The target audience of the resource is not dis-

turbed by incoming mails or messages (unless

notiﬁcation is desired), yet it is shared and seen

presently

• Document is listed in the provided resources of

the clients of the target audience

• Document is not downloaded automatically, but

upon request

• The resources are not only kept on clients, but on

reliable (versioned) repository servers

• Document exchange can be monitored and traced

INSTANT COLLABORATION - Developing a Framework to Support New Patterns of Team-Cooperation

• As the document is stored in a document repos-

itory/CMS, it can be used by other applications

like the web-publishing infrastructure, the full text

indexing and so on

If a user is interested in this provided information,

she can download it, annotate it (in a “BLOG-like”

style) or put new versions on the server.

Also traceability is guaranteed: ﬁrst of all via the

repository/CMS, and secondly also within the system;

e.g., for new users: consider a new user joining a

workgroup: as soon as the administrator gives him

an account and assigns him to one or more groups, he

sees all his colleagues including contact information,

plus all resources that are “published”, plus all anno-

tations that were made to a speciﬁc document, etc.

The root node has a speciﬁc notion in the group

list. This node actually means world (whatever world

means in the very context of the system). The idea

here is (depending on the conﬁguration of the sys-

tem) that every user can easily publish information

in a “BLOG”-like style. To give an example: a secre-

tary could drag a picture of the last event to the world

node, then add some meta-information (like title and

description); then JMellow publishes this picture with

the according meta-information via the CMS on the

corporate News page.

Features for the next versions of our research pro-

totype go some steps beyond: in our notion, instant

collaboration should also allow to let different sys-

tems interact with each other; i.e., it should be possi-

ble to associate resources to chats and vice versa. The

idea is to provide users a history of their chat sessions

with connected documents; even the other way round:

it should be possible to annotate documents (like in

the current version), but also chat about documents

and see this chat associated with the document.

We are also working in integration of the JMel-

low client in other (communication) applications. The

ﬁrst (obvious) step is to write a plugin for a popular

Jabber Client (Spark (Spark IM Client, 2006)). Other

steps should include a plugin for the Mozilla Thun-

derbird mail client using XUL (Thunderbird, 2006).

This allows integration (as described before), but this

time between emails, chat and resources.

4 RELATED WORK AND

APPLICATION CONTEXT

In the previous section we gave an introduction of

the term instant collaboration and provided our con-

cept as well as a brief description of the JMellow

implementation. Currently, several other projects

provide comparable functionality, at least for some

domains: Cryptoheaven (Cryptoheaven, 2003) is a

commercial application, focussing on security, hence,

providing secure email, ﬁle-sharing and IM inte-

grated in a stand-alone application. It also demon-

strated, that there is need for an integrated applica-

tion. Groove (Groove Virtual Ofﬁce, 2006) is also a

commercial application. Various business plans are

considered, reaching from just ﬁle-sharing to screen-

sharing. In 2005 it was acquired by Microsoft and will

apparently not be a platform independent solution.

MyWebdesktop (MyWebdesktop, 2006) is also a

commercial product in beta phase having a web inter-

face for weblink and ﬁle-sharing, which also supports

IM and forums. It demonstrates the feasibility of the

concept working over the internet.

Jogger (Mecham, 2002) shows blogging via a Jab-

ber client, hence, providing easy weblogging func-

tionality that uses instant messaging protocols.

Geyer et al. (Geyer et al., 2003; Millen et al.,

2005) showed an activity-centric desktop using peer-

to-peer technology and shared objects and also pro-

vided a study of the usage of their system (Muller

et al., 2004). However, in our opinion, this work also

demonstrated that it is not necessarily a good idea to

build everything from scratch. We feel, that there is

no need for reinventing the wheel(s) like implement-

ing IM or repository/CMS infrastructure when estab-

lished open source projects are available. Particularly

as there is established open source technology avail-

able to provide this functionality.

A very interesting project was introduced by IBM

research (Jr. et al., 2002): “YouServe” (sometimes

called UServe); The general idea was ﬁle-sharing and

mirroring by using small private webservers. Still, it

appears that this project did not ﬁnd a place in a com-

mercial IBM product, and currently there is hardly in-

formation available about this project any longer.

Besides these more “general purpose” approaches,

there are also very few concrete instant collaboration

projects in speciﬁc domains like designing software

with UML (Hansen and Damm, 2002) or collabora-

tive text-editing (SubEthaEdit, 2006).

From our point of view, the promising paradigm

of instant collaboration—that has to include non-

invasive resource-sharing, versioning, annotation and

eventually the integration of different collaboration

systems—is not yet fulﬁlled by any of the approaches

we found (neither commercially nor as open source

project).

WEBIST 2007 - International Conference on Web Information Systems and Technologies

JMellow

Communication API

Laszlo ServerLaszlo Server

JMellow

Communication API

Laszlo Server

Wildfire

JMellow

Communication API

Laszlo ServerLaszlo ServerLaszlo Server

Repository Server

JMellow Document

Repository API

Daisy

User Client

Communication Interface

& User Administartiom

Document Repository

Laszlo Client

XMPP

HTTP

Laszlo Java RPC

Smack API

service calls & polling

Figure 2: Archtecture of JMellow.

5 JMELLOW ARCHITECTURE

5.1 Components and Design Goals

A JMellow system currently consists of four indepen-

dent software components:

• Communication Layer (JMellow Communication

API)

• User Administration

• Document Repository Server Interface

• User Clients

The communication interface is the link between

the other three components. It allows them to send

events and retrieve callbacks. Every message/event

transport technology like Jabber or JMS could be

used. User Administration manages users and groups.

It creates the ContactList for a user. The generic in-

terface offers the possibility to implement ports to ex-

isting systems like LDAP or Jabber Servers.

The Document Repository Server stores docu-

ments (content and meta data). It generates the user’s

document list and provides methods to fetch docu-

ment content. The JMellow Data Access API can be

a bridge to CMS system or other repository solutions.

(e.g. Jackrabbit)

A User Client is a frontend that offers the chat and

document browsing functionality. It could be a stand-

alone application, a web application or a plugin to an

existing software product.

The JMellow architecture is very ﬂexible. Every

component is independent from the others. We try

not to reinvent the wheel, by implementing very com-

plex functionalities like message transport or a docu-

ment repository with versioning by ourselves, but cre-

ate a framework that makes it possible to plug in ev-

ery suitable existing software. Developers can choose

the right combination of implementations for their cir-

cumstances.

5.2 User Administration

A user is a single person identiﬁed by a unique ID.

Every user can have a human readable alias. Users

are organised into groups. Every user can be part of

one or more groups (this is essentially following the

XMPP speciﬁcation (XMPP Speciﬁcations, 2006)).

Only the administrator can create users and

groups. The user’s contactlist is created on the server

side and sent to the user clients. A user knows only

the groups he’s part of and all the members of these

groups.

5.3 Event Data

Events are sent between the components. Some

events are just method calls (e.g. askForContactList),

some events contain data (e.g. sendMessageToUser)

though. The following types of data could be sent:

ContactList After logging in, the UserClient re-

ceives the contact list containing the structured

groups and users.

UserMessage Represents a chat message to a user in

the contactlist. A one-to-one conversation can be

INSTANT COLLABORATION - Developing a Framework to Support New Patterns of Team-Cooperation

started, similar to ICQ or MSN.

GroupMessage Represents a message to a group.

Everyone in this group receives the message. An

IRC-like chatroom is opened for the group.

DocumentList The user receives a list of all docu-

ments he has access to. The list only contains the

meta data like name, id, date and type.

DocumentContent Represents the content of a doc-

ument. This could be a text-ﬁle, an image-ﬁle or

other binary data. It is possible to send the data

as a binary stream within the the event or to just

provide a URL where the content can be fetched

by the client. Every implementation can choose

what is best concerning the network architecture.

DocumentCommentList A list of all comments at-

tached to the speciﬁc document.

5.4 Communication Layer

The communication layer offers an interface for user

administration, repository server and user clients to

communicate with each other. Various sets of service

methods are provided for different components:

User Client ask for contact list, ask for document

list, send message to user, add/change document

User Administration send contact list to user client,

synchronise user data with document repository

Repository Server send documen tlist, document

content and comments to user client

Some actions require a callback mechanism to tell

the clients that a particular event has arrived. Some

clients may not be able to be called back (e.g. an

Ajax web-application). Therefore we implemented

two different ways of retrieving data. A client can im-

plement a listener interface for callback or the client

may choose a polling mode.

Figure 3 illustrates the login procedure (from

client side) and initialisation step.

As mentioned above, the JMellow concept is

generic, hence, different concrete implementations

and integration of different technologies are feasible,

as seen below:

• Jabber Protocol (e.g. Smack API)

• Java Message Service

• Web Service Calls

• Java RMI

5.5 Document Repository Server

Interface

A JMellow document belongs to one user, called

the document owner. The owner deﬁnes the access

rules for his documents. A document can be read-

able/writeable for just the owner, members of one or

more groups, or everyone. One or more comments

can be added to a document.

The JMellow Document Server Interface is a

transparent layer that exposes the following meth-

ods:add a document, change a document (con-

tent/access rules), get document content, get docu-

ment list. As a storage component, repositories like

JackRabbit or a content managemenet system like

Daisy are conceivable (or an own implementation, of

course).

5.6 User Clients

User Clients are very customisable, including stand-

alone desktop solutions, plugins to existing projects

or web-based applications. Currently we have devel-

oped a Flash prototype using Open Laszlo (Open Las-

zlo, 2006). Other client prototypes are planned (Spark

plugin, mail-client plugin).

5.7 Reference Implementation

Figure 2 illustrates the architecture of the reference

implementation: Wildﬁre provides the Jabber chat

server as well as the user administration. The repos-

itory server synchronises the groups and users with

the wildﬁre database. The repository server is a

servlet running in a Jetty servlet container. It retrieves

calls for documentlist/contents/comments via Jabber

messages within the JMellow communication layer.

This layer uses the Smack Java implementation of the

XMPT protocol (Smack XMPP API, 2006). The calls

are passed to the JMellow document repository in-

terface. This implementation acts as a bridge to the

Cocoon-based CMS Daisy. Daisy provides a straight

forward Java API to manage document actions.

The User Client component contains the Laszlo

presentation server as well as interactive Laszlo Flash

clients that run in every browser with a Flash plugin.

The server—again a servlet in a Jetty—retrieves and

sends messages over the communication layer, sim-

ilar to the repository server. We use Laszlo’s built-

in JavaRPC technology to connect the Flash client

to the business logic on the server. This technology

offers the possibilty to call service methods on the

server easily. These methods include e.g. sendMes-

sageTo. . . -methods as well as the call to the polling

WEBIST 2007 - International Conference on Web Information Systems and Technologies

: UserClient

: CommunicationInterface

: RepositoryServer

: UserAdministration

: logIn

: login

: sendContactList

: contactListReceived

: sendDocumentList

: documentListReceived

Figure 3: Initialisation Process at User login.

method getQueue(). The DocumentContent event

doesn’t contain the actual binary data but an HTTP

URL, so that we can use Laszlo’s implementation of

displaying media over the HTTP protocol. This op-

tion is conﬁgurable for every user client. Some clients

may need to get the binary content straight out of the

event.

6 CONCLUSION AND FURTHER

WORK

Instant Collaboration moves a step ahead from asyn-

chronous resource-sharing and usage of multiple-

client applications for communication and collabo-

ration, towards a role-based synchronous sharing of

resources using integrated client tools, but accessing

proven back-end technologies. In this paper we intro-

duced the concept of instant collaboration and pre-

sented a ﬁrst research prototype to support initial in-

stant collaboration patterns. This prototype is partly a

ﬂexible middleware to integrate established back-end

services with an API to support different client im-

plementations. At the ﬁrst step, we developed a Flash

(Open Laszlo) rich internet client. Further client im-

plementations are planned (Ajax, IM plugin, email in-

tegration) as well as enriching the client functionality,

e.g., with threaded Chat (Smith et al., 2000) and the

option to assign documents/resources to chats.

The next conceptual steps are enriching the mid-

dleware side with the integration of more protocols

(like WebDAV, LDAP, IMAP), which has been done

in the web-application domain in our group, but

not for instant collaboration (Kastner, 2005). Addi-

tionally, support for ad-hoc workﬂows, particularly

in combination with email and document-ﬂows is

planned.

REFERENCES

Apache Licence (2006). Apache open source licence.

http://www.apache.org/licenses/LICENSE-2.0.html.

Bhagyavati, B. (2005). Instant messaging usage policies en-

able ubiquitous communication. In Wireless Telecom-

munications Symposium, 2005, pages 45–48, GA,

USA. Columbus State Univ.

BSCW (2003). BSCW basic support for collaborative work.

http://www.bscw.de/.

Cryptoheaven (2003). Cryptoheaven: secure collaboration.

http://www.cryptoheaven.com/.

Daisy CMS (2006). Daisy content management system.

http://cocoondev.org/daisy/index.html.

Geyer, W., Vogel, J., Cheng, L.-T., and Muller, M.

(2003). Supporting activity-centric collaboration

through peer-to-peer shared objects. In GROUP ’03:

Proceedings of the 2003 international ACM SIG-

GROUP conference on Supporting group work, pages

115–124, New York, NY, USA. ACM Press.

Groove Virtual Ofﬁce (2006). Microsoft: Groove virtual

ofﬁce. http://groove.net.

Grudin, J. (1988). Why cscw applications fail: problems in

the design and evaluation of organization of organiza-

tional interfaces. In Proceedings of the Conference on

Computer-Supported Cooperative Work, pages 85–93.

ACM Press.

Hansen, K. M. and Damm, C. H. (2002). Instant collabo-

ration: using context-aware instant messaging for ses-

sion management in distributed collaboration tools. In

NordiCHI ’02: Proceedings of the second Nordic con-

ference on Human-computer interaction, pages 279–

282, New York, NY, USA. ACM Press.

Jackrabbit Content Repository (2006). Jackrabbit jsr-170

content repository. http://jackrabbit.apache.org/.

Jr., R. J. B., Agrawal, R., Gruhl, D., and Somani, A. (2002).

Youserv: a web-hosting and content sharing tool for

the masses. In WWW ’02: Proceedings of the 11th

international conference on World Wide Web, pages

345–354, New York, NY, USA. ACM Press.

INSTANT COLLABORATION - Developing a Framework to Support New Patterns of Team-Cooperation

Kastner, T. (2005). Document management in distributed

project management environments-a new interface ap-

proach. Master’s thesis, Vienna University of Tech-

nology.

Mandviwalla, M. and Olfman, L. (1994). What do groups

need? a proposed set of generic groupware re-

quirements. ACM Trans. Comput.-Hum. Interact.,

1(3):245–268.

Mecham, J. (2002). Jogger. http://jabber.linux.it/jogger/.

Millen, D. R., Muller, M. J., Geyer, W., Wilcox, E., and

Brownholtz, B. (2005). Patterns of media use in an

activity-centric collaborative environment. In CHI

’05: Proceedings of the SIGCHI conference on Hu-

man factors in computing systems, pages 879–888,

New York, NY, USA. ACM Press.

Muller, M. J., Geyer, W., Brownholtz, B., Wilcox, E., and

Millen, D. R. (2004). One-hundred days in an activity-

centric collaboration environment based on shared ob-

jects. In CHI ’04: Proceedings of the SIGCHI confer-

ence on Human factors in computing systems, pages

375–382, New York, NY, USA. ACM Press.

MyWebdesktop (2006). Mywebdesktop.

http://www.mywebdesktop.net/. still in beta.

Nuescheler, D. (2006). Java speciﬁcation request: JSR-170

content repository. Technical report, Sun Microsys-

tems.

Open Laszlo (2006). Open laszlo; framework to create rich

internet applications. http://www.openlaszlo.org/.

Smack XMPP API (2006). Smack xmpp api for java (jive

software). http://jivesoftware.org/smack/.

Smith, M., Cadiz, J. J., and Burkhalter, B. (2000). Con-

versation trees and threaded chats. In CSCW ’00:

Proceedings of the 2000 ACM conference on Com-

puter supported cooperative work, pages 97–105,

New York, NY, USA. ACM Press.

Spark IM Client (2006). Spark jabber instant messaging

client (jive software). http://jivesoftware.org/spark/.

SubEthaEdit (2006). Subethaedit: Collaborative editing ap-

plication. http://codingmonkeys.de/subethaedit/.

Thunderbird (2006). Mozilla thunderbird email client.

http://www.mozilla.com/thunderbird/.

Wildﬁre Server (2006). Wildﬁre xmpp (jabber) server, jive

software. http://jivesoftware.org/wildﬁre/.

XMPP Speciﬁcations (2006). Xmpp speciﬁcations.

http://www.xmpp.org/.

WEBIST 2007 - International Conference on Web Information Systems and Technologies