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
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
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
On Saturday 30 May 2009 07:54:16 Roger Pixley wrote:
> 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)
I was speaking from a purely API standpoint, my knowledge of jabber is somewhat lacking. Creating chat outside of a document would mean major changes to the libinfinity API because user information is specified on a per-
document basis, so im not sure the libinfinity devs would go for this. Maybe a feature request for document level chat should be forwarded to them?
> 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
Just had a light chat with the devs and they had wanted caht removed from
the API altogether. I have yet to speak to the person (ck) who has final
word on this but I'm thinking that it falls more in ine with the original
submission that I had made of having a light serer that focuses solely on
the document and sharing it and a heavier specification that is much more
workflow oriented. Well as it stands the spec has a jabber implementation
that is server wide. Lets see what amendments they are conducive to making
and work with that.
On Sat, May 30, 2009 at 2:18 PM, Gregory Haynes <g...@greghaynes.net> wrote:
> On Saturday 30 May 2009 07:54:16 Roger Pixley wrote:
> > 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)
> I was speaking from a purely API standpoint, my knowledge of jabber is
> somewhat lacking. Creating chat outside of a document would mean major
> changes to the libinfinity API because user information is specified on a
> per-
> document basis, so im not sure the libinfinity devs would go for this.
> Maybe a
> feature request for document level chat should be forwarded to them?
> > 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
That makes sense. Something else that could be done, is creating a chat plugin for libinfinity similar to the InfText plugin, but with chat operations instead of insert/remove text operations. I dont see any reason why this wouldnt work, and clients which dont recognize the plugin would not be effected.
On Sunday 31 May 2009 03:53:05 Roger Pixley wrote:
> Just had a light chat with the devs and they had wanted caht removed from > the API altogether. I have yet to speak to the person (ck) who has final > word on this but I'm thinking that it falls more in ine with the original > submission that I had made of having a light serer that focuses solely on > the document and sharing it and a heavier specification that is much more > workflow oriented. Well as it stands the spec has a jabber implementation > that is server wide. Lets see what amendments they are conducive to making > and work with that.
> On Sat, May 30, 2009 at 2:18 PM, Gregory Haynes <g...@greghaynes.net> wrote: > > On Saturday 30 May 2009 07:54:16 Roger Pixley wrote: > > > 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)
> > I was speaking from a purely API standpoint, my knowledge of jabber is > > somewhat lacking. Creating chat outside of a document would mean major > > changes to the libinfinity API because user information is specified on a > > per- > > document basis, so im not sure the libinfinity devs would go for this. > > Maybe a > > feature request for document level chat should be forwarded to them?
> > > 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
Creating and joining a MUC (a channel in XMPP speak) is pretty trivial
and definitely should be worked into the architecture.
I just saw a demo of Google WAVE recently and really liked what they
had implemented.
http://wave.google.com/ It really inspired me on a few fronts for what collaboration could be like.
The features Google presented within in the first 10 minutes of the
demo already had me convinced that they were on the right path. As I
understand it, they based it on XMPP and added an extension to XMPP to
enable short UDP like messages over XMPP to make XMPP suitable for
real-time character-by-character updates which I thought was a great
thing.
Watch it for inspiration, or even consider using the WAVE protocol
they are offering (or read their white papers on how they addressed
some of the same issues).
The way they addressed the "channels" topic is they give a unique ID
to the "wave" (top level document) and another Unique ID to each
wavelet (message within that document). Each wave essentially becomes
its own "channel".
I definitely believe that real time collaboration on a document MUST
have a way for the collaborators to communicate about what they are
working on. Having a voice&video or chat feed enabling the
collaboraters to discuss while they edit is important.
I also see the "multiple channels per document" being important for
architectual reasons beyond chat. The best example I have would be
collaborating on some source code. The source code document would be
in one channel, but compiler errors would be great to have on another
channel.
It's also not too hard to imagine the need for multiple "source code"
channels (one for each file) all having a common compilation and chat
channels. In the Wave demonstration they implemented some 'bots' that
participated server side in the collaboration. Imagine a compilation
bot participating in the document sending messages on the
'compilation' channel. Source code to me is a great example of how
multiple "documents" make up a single thing to collaborate on and how
you can't really work on one document in total isolation of the
others.
From what I've read here, it sounds to me like the focus has been on
collaborating on a "Document" and I think what's needed is to abstract
that one step further and have multiple participants in a "Workspace".
Multiple applications could be bound to that single WorkSpace and the
text chat would be one "Document" in the WorkSpace, and the Document
itself would be another "Document", and the voice&video feed would a
third "Document" in the WorkSpace. (It seems that "Document" now
needs to be renamed in this example... Stream... Application... or as
Google called it, Wave.)
From a security standpoint, ultimately each Document should require a
separate authorization but in the meantime, participation in the main
WorkSpace stream would authorize that participant for all Documents in
the Workspace.
So here's a suggestion to implement this without adding any code to
implement using the MUC.
At the top level folks collaborate on WorkSpaces (instead of Document).
On creating or joining a WorkSpace, the application provides an
DocTypeID (perhaps based on Mime-Type).
The combination of a WorkSpace and a DocTypeID is a "Document".
A WorkSpace is simply a Namespace to hold the list of "Documents" that
are participating in that WorkSpace.
For the time being, folks would have to open multiple applications and
separately join each application to the same WorkSpace to particpate
in all the aspects of the WorkSpace. The chat application would get
the "text/IM" messages and the text editor would get the "text/plain"
messages. Internally they'd all be separate Documents so the library
is none the wiser except for that users only see individual Documents
through the WorkSpace metaphor.
If Mime-Type is too generic since that implies different applications.
Then instead of a DocTypeID, use an InterfaceID. The WorkSpace
"HelloWorld.txt" might have InterfaceIDs "KateV1.0" and "XMPPV1.0".
The idea being that each Application would implement its own custom
message protocol. By versioning the named protocol, applications
would then be able to determine if they could participate in that
Document.
On Sat, May 30, 2009 at 10:17 PM, Gregory Haynes<g...@greghaynes.net> wrote:
> That makes sense. Something else that could be done, is creating a chat
> plugin for libinfinity similar to the InfText plugin, but with chat operations
> instead of insert/remove text operations. I dont see any reason why this
> wouldnt work, and clients which dont recognize the plugin would not be
> effected.
> On Sunday 31 May 2009 03:53:05 Roger Pixley wrote:
>> Just had a light chat with the devs and they had wanted caht removed from
>> the API altogether. I have yet to speak to the person (ck) who has final
>> word on this but I'm thinking that it falls more in ine with the original
>> submission that I had made of having a light serer that focuses solely on
>> the document and sharing it and a heavier specification that is much more
>> workflow oriented. Well as it stands the spec has a jabber implementation
>> that is server wide. Lets see what amendments they are conducive to making
>> and work with that.
>> On Sat, May 30, 2009 at 2:18 PM, Gregory Haynes <g...@greghaynes.net> wrote:
>> > On Saturday 30 May 2009 07:54:16 Roger Pixley wrote:
>> > > 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)
>> > I was speaking from a purely API standpoint, my knowledge of jabber is
>> > somewhat lacking. Creating chat outside of a document would mean major
>> > changes to the libinfinity API because user information is specified on a
>> > per-
>> > document basis, so im not sure the libinfinity devs would go for this.
>> > Maybe a
>> > feature request for document level chat should be forwarded to them?
>> > > 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.
On Monday 08 June 2009 21:48:40 Michael Fair wrote:
> Creating and joining a MUC (a channel in XMPP speak) is pretty trivial > and definitely should be worked into the architecture.
> I just saw a demo of Google WAVE recently and really liked what they > had implemented. > http://wave.google.com/ > It really inspired me on a few fronts for what collaboration could be like.
I have also been researching this new technology and trying to determine its possible impacts on existing collaborative applications. While Wave seems to offer a slew of collaborative features, it seems like it would be very difficult to integrate all of these in a client-side feature-rich editor, like Kate. For example, im not sure how the Document::View component would handle embedded images/conversations mid-document along with syntax highlighting? Even so, I do agree there is a lot to learn from the Wave project and the current Wave web client.
> The features Google presented within in the first 10 minutes of the > demo already had me convinced that they were on the right path. As I > understand it, they based it on XMPP and added an extension to XMPP to > enable short UDP like messages over XMPP to make XMPP suitable for > real-time character-by-character updates which I thought was a great > thing.
> Watch it for inspiration, or even consider using the WAVE protocol > they are offering (or read their white papers on how they addressed > some of the same issues).
> The way they addressed the "channels" topic is they give a unique ID > to the "wave" (top level document) and another Unique ID to each > wavelet (message within that document). Each wave essentially becomes > its own "channel".
Although interesting, its definately a Pie in deep space seeing as their protocol is not expected to be finalized anytime this year.
> I definitely believe that real time collaboration on a document MUST > have a way for the collaborators to communicate about what they are > working on. Having a voice&video or chat feed enabling the > collaboraters to discuss while they edit is important.
> I also see the "multiple channels per document" being important for > architectual reasons beyond chat. The best example I have would be > collaborating on some source code. The source code document would be > in one channel, but compiler errors would be great to have on another > channel.
> It's also not too hard to imagine the need for multiple "source code" > channels (one for each file) all having a common compilation and chat > channels. In the Wave demonstration they implemented some 'bots' that > participated server side in the collaboration. Imagine a compilation > bot participating in the document sending messages on the > 'compilation' channel. Source code to me is a great example of how > multiple "documents" make up a single thing to collaborate on and how > you can't really work on one document in total isolation of the > others.
Im not sure how this relates to libqinfinity/Kobby? These alreay allow editing of multiple documents simultaniously.
> From what I've read here, it sounds to me like the focus has been on > collaborating on a "Document" and I think what's needed is to abstract > that one step further and have multiple participants in a "Workspace". > Multiple applications could be bound to that single WorkSpace and the > text chat would be one "Document" in the WorkSpace, and the Document > itself would be another "Document", and the voice&video feed would a > third "Document" in the WorkSpace. (It seems that "Document" now > needs to be renamed in this example... Stream... Application... or as > Google called it, Wave.)
Actually, libinfinity does exactly this. Although it is called a 'note' rather than a workspace, the concept of a note is completely abstract in that it only allows plugins to register possible operations for various note types. All text editing done in libinfinity curretly is done via the InfText plugin, for example.
> From a security standpoint, ultimately each Document should require a > separate authorization but in the meantime, participation in the main > WorkSpace stream would authorize that participant for all Documents in > the Workspace.
> So here's a suggestion to implement this without adding any code to > implement using the MUC. > At the top level folks collaborate on WorkSpaces (instead of Document). > On creating or joining a WorkSpace, the application provides an > DocTypeID (perhaps based on Mime-Type). > The combination of a WorkSpace and a DocTypeID is a "Document". > A WorkSpace is simply a Namespace to hold the list of "Documents" that > are participating in that WorkSpace.
> For the time being, folks would have to open multiple applications and > separately join each application to the same WorkSpace to particpate > in all the aspects of the WorkSpace. The chat application would get > the "text/IM" messages and the text editor would get the "text/plain" > messages. Internally they'd all be separate Documents so the library > is none the wiser except for that users only see individual Documents > through the WorkSpace metaphor.
> If Mime-Type is too generic since that implies different applications. > Then instead of a DocTypeID, use an InterfaceID. The WorkSpace > "HelloWorld.txt" might have InterfaceIDs "KateV1.0" and "XMPPV1.0". > The idea being that each Application would implement its own custom > message protocol. By versioning the named protocol, applications > would then be able to determine if they could participate in that > Document.
Wow I"m late on jumping in on this :-) Ok here are my thoughts at least on a
desktop level I've already pitched my concept of clients being able to be
light or heavy servers. I also don't see any reason why they cannot be light
and heavy clients. A heavy client would be one that tries to tie together
all aspects of the workflow as far as it can be pushed for the purpose of
the application.
This is somewhat like an IDE versus a text editor One tries to catch every
corner case and one simply does some thing very well and leaves other things
to do other related work. Kate is a special case in that it simply embeds
kparts that do the other sections of work and becomes more of a switchblade
swiss army knife.
A light client would be cognizant of specific things but could prompt you of
other collaboration possibilities available and the desktop or collaboration
manager could offer registered programs that can handle that. Kopete for
quick chat Krita for Shared images etc. Of course a very light client would
simply drop or ignore anything that it didn't care about for cases like
collaboration on a mobile device but this discussion is about a Kobby :)
If you are thinking of documents you will be missing things like Film and
music and images all of which can be looked at as a
kollaboration opportunity.
Greg I had wanted to ask if the server you had announced for GCDS was
intended as a development server or a kind of standalone test. We have had a
lot of sprints and it would be useful for both you and them to have
something up to work with and to see how it gets used.
On Wed, Jun 10, 2009 at 2:44 AM, Gregory Haynes <g...@greghaynes.net> wrote:
> On Monday 08 June 2009 21:48:40 Michael Fair wrote:
> > Creating and joining a MUC (a channel in XMPP speak) is pretty trivial
> > and definitely should be worked into the architecture.
> > I just saw a demo of Google WAVE recently and really liked what they
> > had implemented.
> > http://wave.google.com/ > > It really inspired me on a few fronts for what collaboration could be
> like.
> I have also been researching this new technology and trying to determine
> its
> possible impacts on existing collaborative applications. While Wave seems
> to
> offer a slew of collaborative features, it seems like it would be very
> difficult
> to integrate all of these in a client-side feature-rich editor, like Kate.
> For example, im not sure how the Document::View component would handle
> embedded images/conversations mid-document along with syntax highlighting?
> Even so, I do agree there is a lot to learn from the Wave project and the
> current Wave web client.
> > The features Google presented within in the first 10 minutes of the
> > demo already had me convinced that they were on the right path. As I
> > understand it, they based it on XMPP and added an extension to XMPP to
> > enable short UDP like messages over XMPP to make XMPP suitable for
> > real-time character-by-character updates which I thought was a great
> > thing.
> > Watch it for inspiration, or even consider using the WAVE protocol
> > they are offering (or read their white papers on how they addressed
> > some of the same issues).
> > The way they addressed the "channels" topic is they give a unique ID
> > to the "wave" (top level document) and another Unique ID to each
> > wavelet (message within that document). Each wave essentially becomes
> > its own "channel".
> Although interesting, its definately a Pie in deep space seeing as their
> protocol is not expected to be finalized anytime this year.
> > I definitely believe that real time collaboration on a document MUST
> > have a way for the collaborators to communicate about what they are
> > working on. Having a voice&video or chat feed enabling the
> > collaboraters to discuss while they edit is important.
> > I also see the "multiple channels per document" being important for
> > architectual reasons beyond chat. The best example I have would be
> > collaborating on some source code. The source code document would be
> > in one channel, but compiler errors would be great to have on another
> > channel.
> > It's also not too hard to imagine the need for multiple "source code"
> > channels (one for each file) all having a common compilation and chat
> > channels. In the Wave demonstration they implemented some 'bots' that
> > participated server side in the collaboration. Imagine a compilation
> > bot participating in the document sending messages on the
> > 'compilation' channel. Source code to me is a great example of how
> > multiple "documents" make up a single thing to collaborate on and how
> > you can't really work on one document in total isolation of the
> > others.
> Im not sure how this relates to libqinfinity/Kobby? These alreay allow
> editing
> of multiple documents simultaniously.
> > From what I've read here, it sounds to me like the focus has been on
> > collaborating on a "Document" and I think what's needed is to abstract
> > that one step further and have multiple participants in a "Workspace".
> > Multiple applications could be bound to that single WorkSpace and the
> > text chat would be one "Document" in the WorkSpace, and the Document
> > itself would be another "Document", and the voice&video feed would a
> > third "Document" in the WorkSpace. (It seems that "Document" now
> > needs to be renamed in this example... Stream... Application... or as
> > Google called it, Wave.)
> Actually, libinfinity does exactly this. Although it is called a 'note'
> rather
> than a workspace, the concept of a note is completely abstract in that it
> only
> allows plugins to register possible operations for various note types. All
> text editing done in libinfinity curretly is done via the InfText plugin,
> for
> example.
> > From a security standpoint, ultimately each Document should require a
> > separate authorization but in the meantime, participation in the main
> > WorkSpace stream would authorize that participant for all Documents in
> > the Workspace.
> > So here's a suggestion to implement this without adding any code to
> > implement using the MUC.
> > At the top level folks collaborate on WorkSpaces (instead of Document).
> > On creating or joining a WorkSpace, the application provides an
> > DocTypeID (perhaps based on Mime-Type).
> > The combination of a WorkSpace and a DocTypeID is a "Document".
> > A WorkSpace is simply a Namespace to hold the list of "Documents" that
> > are participating in that WorkSpace.
> See above comment on Infinote notes.
> > For the time being, folks would have to open multiple applications and
> > separately join each application to the same WorkSpace to particpate
> > in all the aspects of the WorkSpace. The chat application would get
> > the "text/IM" messages and the text editor would get the "text/plain"
> > messages. Internally they'd all be separate Documents so the library
> > is none the wiser except for that users only see individual Documents
> > through the WorkSpace metaphor.
> > If Mime-Type is too generic since that implies different applications.
> > Then instead of a DocTypeID, use an InterfaceID. The WorkSpace
> > "HelloWorld.txt" might have InterfaceIDs "KateV1.0" and "XMPPV1.0".
> > The idea being that each Application would implement its own custom
> > message protocol. By versioning the named protocol, applications
> > would then be able to determine if they could participate in that
> > Document.
> Greg I had wanted to ask if the server you had announced for GCDS was > intended as a development server or a kind of standalone test. We have > had a lot of sprints and it would be useful for both you and them to > have something up to work with and to see how it gets used.
I figured the server had fallen off everyone's radar. It definitely would be useful for me if it were to be used so I just put it back up: infinote.greghaynes.net
Ok I'll make an announcement for it for sprints and general tests. What
other filters have been done for infinote other than Text? Would it be too
forward to say that if a Suite of programs handles formats in a particular
way they should write a filter to allow remote kollaboration throughout the
suite rather than waiting for a general purpose filter to work with them?
On Thu, Nov 5, 2009 at 1:24 PM, Gregory Haynes <g...@greghaynes.net> wrote:
> > Greg I had wanted to ask if the server you had announced for GCDS was
> > intended as a development server or a kind of standalone test. We have
> > had a lot of sprints and it would be useful for both you and them to
> > have something up to work with and to see how it gets used.
> I figured the server had fallen off everyone's radar. It definitely
> would be useful for me if it were to be used so I just put it back up:
> infinote.greghaynes.net
|
