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.164 as permitted sender) client-ip=209.85.220.164;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Oz78auCac7+eDlEM3mBmnN5Nst+WUWVzsaofQxGGEatCNlWoYSefgl986JBB0Ca0jQ
         IWcIqOm4FqnvX8gfR5E/JCc9OG5svpcfs3J2E3609ILly7+Dgokn9ZSMloCe7ZWM1QyJ
         QNfigM1oQYtP8Pbp+mAN0KpvGYaAXdoWCGiMU=
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="001636c5bcc5e8ae0a046b1c7f50"
In-Reply-To: <200905300705.27262.greg@greghaynes.net>
References: <3246ed240905292242nef76a4ch6a425e7449f9aace@mail.gmail.com>
	 <200905300705.27262.g...@greghaynes.net>
Date: Sat, 30 May 2009 02:54:16 -0500
Message-ID: <3246ed240905300054j335fb6b9k582616025d540...@mail.gmail.com>
Subject: Re: Communication while Editing.
From: Roger Pixley <skree...@gmail.com>
To: kollaborative-frame@googlegroups.com

--001636c5bcc5e8ae0a046b1c7f50
Content-Type: text/plain; charset=ISO-8859-1

On a server level this would certainly mean a major API change, but I dont
see
why this would be difficult to implement on a document level.  User
information
is already provided when joining a document, so maybe a chat facility could
be
retrieved after joining a session?

 So simply spawn a new Channel? I know it's all Jabber based so technically
this is possible but then would the user have a channel per document witn
one extra covering the whole server?  If that's possible that's the second
best outcome I can think of (The best being able to have a group chat
without tying it toa document that way you can have a group of users
chatting which can be tied to 0 1 or many documents)


On Sat, May 30, 2009 at 2:05 AM, Gregory Haynes <g...@greghaynes.net> wrote:

>
>
>
> On Saturday 30 May 2009 05:42:55 Roger Pixley wrote:
> > Sending this out to the list to garner some mindmash. Currently
> libinfinity
> > (and hence libqinfinity) supports communication by Jabber on a server
> > level.
>
> I did some digging around in the libinfinity API for communication
> features,
> and AFAICT there are no document or server level user to user chat
> facilities
> in the library.  This could be (relatively) easily added on a document
> level
> via a note plugin without having to modify libinfinity.  Ill send out a
> message
> to Armin to make sure this is correct.
>
> > 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.
>
> On a server level this would certainly mean a major API change, but I dont
> see
> why this would be difficult to implement on a document level.  User
> information
> is already provided when joining a document, so maybe a chat facility could
> be
> retrieved after joining a session?
>
> > 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
>
> --
> Gregory Haynes
>
> >
>

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

On a server level this would certainly mean a major API change, but I dont =
see<br>
why this would be difficult to implement on a document level. =A0User infor=
mation<br>
is already provided when joining a document, so maybe a chat facility could=
 be<br>
retrieved after joining a session?<br><br>
<div class=3D"im">=A0So simply spawn a new Channel? I know it&#39;s all Jab=
ber based so technically this is possible but then would the user have a ch=
annel per document witn one extra covering the whole server?=A0 If that&#39=
;s possible that&#39;s the second best outcome I can think of (The best bei=
ng able to have a group chat without tying it toa document that way you can=
 have a group of users chatting which can be tied to 0 1 or many documents)=
<br>
</div><br><br><div class=3D"gmail_quote">On Sat, May 30, 2009 at 2:05 AM, G=
regory Haynes <span dir=3D"ltr">&lt;<a href=3D"mailto:g...@greghaynes.net">=
g...@greghaynes.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt=
 0.8ex; padding-left: 1ex;">
<div class=3D"im"><br>
<br>
<br>
On Saturday 30 May 2009 05:42:55 Roger Pixley wrote:<br>
&gt; Sending this out to the list to garner some mindmash. Currently libinf=
inity<br>
&gt; (and hence libqinfinity) supports communication by Jabber on a server<=
br>
&gt; level.<br>
<br>
</div>I did some digging around in the libinfinity API for communication fe=
atures,<br>
and AFAICT there are no document or server level user to user chat faciliti=
es<br>
in the library. =A0This could be (relatively) easily added on a document le=
vel<br>
via a note plugin without having to modify libinfinity. =A0Ill send out a m=
essage<br>
to Armin to make sure this is correct.<br>
<div class=3D"im"><br>
&gt; For quite a few reasons I think that having an option to have it on<br=
>
&gt; a document level is a good idea. If you think of a large assembly such=
 as<br>
&gt; Akademy or GCDS (Side Thought: How do you abstract that? *DS?) =A0wher=
e you<br>
&gt; would like an easy one connect server for remote collaborators but the=
n<br>
&gt; having all the chatter for the various projects and problems being<br>
&gt; discussed broadcast to everyone is unbearably confusing. Or further do=
wn<br>
&gt; the line when this is KDE wide and many types of clients can connect t=
o it<br>
&gt; (also FOSS now rules the world cause the others ignored then laughed t=
hen<br>
&gt; fought ) A fairly large business would want to use something like this=
<br>
&gt; internally to tie together teams. Even if there is one server per<br>
&gt; department you would want discussions to be more localized to say a gr=
oup<br>
&gt; or a document.<br>
&gt;<br>
&gt; So having said that I think that a proposal currently to implemt prope=
r<br>
&gt; channels and identifucation would be thrown out right away as somethin=
g too<br>
&gt; disruptive to do now.<br>
<br>
</div>On a server level this would certainly mean a major API change, but I=
 dont see<br>
why this would be difficult to implement on a document level. =A0User infor=
mation<br>
is already provided when joining a document, so maybe a chat facility could=
 be<br>
retrieved after joining a session?<br>
<div class=3D"im"><br>
&gt; My proposal is to allow messages which are sent to be<br>
&gt; optionally tagged then clients can read the tags on the messages and r=
eact<br>
&gt; as they see fit. Clients who have no idea about the tags will just dro=
p<br>
&gt; them Clients who know but don&#39;t really care can possibly simply di=
splay the<br>
&gt; tags Clients that know and care can create channels or drop entire mes=
sages<br>
&gt; of the user doesn&#39;t care about them etc.<br>
&gt;<br>
&gt; If anyone has another solution to the issue or sees the issue in a<br>
&gt; different light please reply and lets have a discussion :)<br>
&gt;<br>
&gt; Roger Pixley<br>
&gt; Sharer of Sentiments<br>
&gt; Kollaborator of Konsiderations<br>
<br>
</div>--<br>
Gregory Haynes<br>
<br>
<br>
</blockquote></div><br>

--001636c5bcc5e8ae0a046b1c7f50--