Communication while Editing. - Kollaborative Frame

Message from discussion Communication while Editing.
Received-SPF: pass (google.com: domain of skree...@gmail.com designates 209.85.220.213 as permitted sender) client-ip=209.85.220.213;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=rdEKzGLOvFmXlIaZZdWUMmdKYEL73iNAt3oScV1zMyT2gtillWdU2c4iShTRMaW1VH
         mxR+43hTmUn+KF25TBUJDaK3EL3nVFTifkESypDWL7AcCCM9ZQJrNy+mF36FCKdUh6Eo
         fVs99Xt8Kt4rbQQ9teZEjTOVavtDhTOfSIleI=
MIME-Version: 1.0
Date: Sat, 30 May 2009 00:42:55 -0500
Message-ID: <3246ed240905292242nef76a4ch6a425e7449f9aace@mail.gmail.com>
Subject: Communication while Editing.
From: Roger Pixley <skree...@gmail.com>
To: kollaborative-frame <kollaborative-frame@googlegroups.com>
Content-Type: multipart/alternative; boundary=001636c5abdf2ab49e046b1aaabf

--001636c5abdf2ab49e046b1aaabf
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Sending this out to the list to garner some mindmash. Currently libinfinity
(and hence libqinfinity) supports communication by Jabber on a server level.
For quite a few reasons I think that having an option to have it on a
document level is a good idea. If you think of a large assembly such as
Akademy or GCDS (Side Thought: How do you abstract that? *DS?)  where you
would like an easy one connect server for remote collaborators but then
having all the chatter for the various projects and problems being discussed
broadcast to everyone is unbearably confusing. Or further down the line when
this is KDE wide and many types of clients can connect to it (also FOSS now
rules the world cause the others ignored then laughed then fought ) A fairly
large business would want to use something like this internally to tie
together teams. Even if there is one server per department you would want
discussions to be more localized to say a group or a document.

So having said that I think that a proposal currently to implemt proper
channels and identifucation would be thrown out right away as something too
disruptive to do now. My proposal is to allow messages which are sent to be
optionally tagged then clients can read the tags on the messages and react
as they see fit. Clients who have no idea about the tags will just drop them
Clients who know but don't really care can possibly simply display the tags
Clients that know and care can create channels or drop entire messages of
the user doesn't care about them etc.

If anyone has another solution to the issue or sees the issue in a different
light please reply and lets have a discussion :)

Roger Pixley
Sharer of Sentiments
Kollaborator of Konsiderations

--001636c5abdf2ab49e046b1aaabf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sending this out to the list to garner some mindmash. Currently libinfinity=
 (and hence libqinfinity) supports communication by Jabber on a server leve=
l. For quite a few reasons I think that having an option to have it on a do=
cument level is a good idea. If you think of a large assembly such as Akade=
my or GCDS (Side Thought: How do you abstract that? *DS?)=A0 where you woul=
d like an easy one connect server for remote collaborators but then having =
all the chatter for the various projects and problems being discussed broad=
cast to everyone is unbearably confusing. Or further down the line when thi=
s is KDE wide and many types of clients can connect to it (also FOSS now ru=
les the world cause the others ignored then laughed then fought ) A fairly =
large business would want to use something like this internally to tie toge=
ther teams. Even if there is one server per department you would want discu=
ssions to be more localized to say a group or a document. <br>
<br>So having said that I think that a proposal currently to implemt proper=
 channels and identifucation would be thrown out right away as something to=
o disruptive to do now. My proposal is to allow messages which are sent to =
be optionally tagged then clients can read the tags on the messages and rea=
ct as they see fit. Clients who have no idea about the tags will just drop =
them Clients who know but don&#39;t really care can possibly simply display=
 the tags Clients that know and care can create channels or drop entire mes=
sages of the user doesn&#39;t care about them etc. <br>
<br>If anyone has another solution to the issue or sees the issue in a diff=
erent light please reply and lets have a discussion :)<br><br>Roger Pixley<=
br>Sharer of Sentiments<br>Kollaborator of Konsiderations<br>

--001636c5abdf2ab49e046b1aaabf--