Suggestions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Suggestions

cenourinha gmail
Hi there, i have some suggestions to make.

- Multi-user control;
- Read/write Permissions;
- Code/Text editor web based for .txt, .html, and other file types
- Music/Video Player for multimedia files
- Space limitations (great for web hosting providers who want to provide web hosting backup solutions with ownCloud)
- Multi-language interface

Regards,
Teot?nio Ricardo
WebTuga, Unipessoal Lda
http://www.webtuga.pt

Reply | Threaded
Open this post in threaded view
|

Suggestions

Hans Bakker
It would also be nice if people could work together on the same document.
The web frontend to this could be integrated with ownCloud while an optional
server could host the simultaneous access. There are several open source
solutions for this like etherpad <http://code.google.com/p/etherpad/> and
Infinote <http://infinote.org/>. Jinfinote <http://www.jinfinote.com/>is a
web frontend to an Infinote server like
Infinoted<http://gobby.0x539.de/trac/wiki/Infinote/Infinoted>.
The nice thing of Infinote is that there are also desktop clients for it
like Kobby <http://kobby.greghaynes.net/home>.

Kind regards,

Hans Bakker

2010/7/8 cenourinha gmail <webtuga at gmail.com>

> Hi there, i have some suggestions to make.
>
> - Multi-user control;
> - Read/write Permissions;
> - Code/Text editor web based for .txt, .html, and other file types
> - Music/Video Player for multimedia files
> - Space limitations (great for web hosting providers who want to provide
> web hosting backup solutions with ownCloud)
> - Multi-language interface
>
> Regards,
> Teot?nio Ricardo
> WebTuga, Unipessoal Lda
> http://www.webtuga.pt
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/owncloud/attachments/20100708/536e7ad7/attachment.htm 

Reply | Threaded
Open this post in threaded view
|

Suggestions

Aldo "xoen" Giambelluca
In reply to this post by cenourinha gmail
2010/7/8 cenourinha gmail <webtuga at gmail.com>:
> Hi there, i have some suggestions to make.
>
> - Multi-user control;
> - Read/write Permissions;
> - Code/Text editor web based for .txt, .html, and other file types
> - Music/Video Player for multimedia files
> - Space limitations (great for web hosting providers who want to provide web hosting backup solutions with ownCloud)
> - Multi-language interface
I'm sure more or less all these are already planned but I'm not sure.

Probably these features should be included into /doc/TODO and/or
discussed here (organizing by
priority/difficulty).




--
Aldo "xoen" Giambelluca <xoen at xoen.org>

Reply | Threaded
Open this post in threaded view
|

Suggestions

Aldo "xoen" Giambelluca
2010/7/8 Aldo "xoen" Giambelluca <xoen at xoen.org>:

> 2010/7/8 cenourinha gmail <webtuga at gmail.com>:
>> Hi there, i have some suggestions to make.
>>
>> - Multi-user control;
>> - Read/write Permissions;
>> - Code/Text editor web based for .txt, .html, and other file types
>> - Music/Video Player for multimedia files
>> - Space limitations (great for web hosting providers who want to provide web hosting backup solutions with ownCloud)
>> - Multi-language interface
> I'm sure more or less all these are already planned but I'm not sure.
I'm sure/I'm not sure, OK I need to sleep :P.

What I mean is, I think these are planned somewhen
(http://owncloud.org/index.php/Roadmap)
but this is just my opinion.



--
Aldo "xoen" Giambelluca <xoen at xoen.org>

Reply | Threaded
Open this post in threaded view
|

Suggestions

Kenny Coyle
I'm quite new to working with OwnCloud (and hoping to develop where I can).

Was there ever a decision made on whether to develop everything from
scratch, or is it OK to use current open source code inside ownCloud.

The reason I ask is primarilly for the text editor... I can see this
being implemented very quickly using TinyMCE. I can see merits to both
starting from scratch or building on top of that...

What do you guys think?

K.

On 8 July 2010 14:52, Aldo "xoen" Giambelluca <xoen at xoen.org> wrote:

> 2010/7/8 Aldo "xoen" Giambelluca <xoen at xoen.org>:
>> 2010/7/8 cenourinha gmail <webtuga at gmail.com>:
>>> Hi there, i have some suggestions to make.
>>>
>>> - Multi-user control;
>>> - Read/write Permissions;
>>> - Code/Text editor web based for .txt, .html, and other file types
>>> - Music/Video Player for multimedia files
>>> - Space limitations (great for web hosting providers who want to provide web hosting backup solutions with ownCloud)
>>> - Multi-language interface
>> I'm sure more or less all these are already planned but I'm not sure.
> I'm sure/I'm not sure, OK I need to sleep :P.
>
> What I mean is, I think these are planned somewhen
> (http://owncloud.org/index.php/Roadmap)
> but this is just my opinion.
>
>
>
> --
> Aldo "xoen" Giambelluca <xoen at xoen.org>
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>

Reply | Threaded
Open this post in threaded view
|

Suggestions

Aldo "xoen" Giambelluca
2010/7/8 Kenny Coyle <kenny at heloo.net>:

> I'm quite new to working with OwnCloud (and hoping to develop where I can).
>
> Was there ever a decision made on whether to develop everything from
> scratch, or is it OK to use current open source code inside ownCloud.
>
> The reason I ask is primarilly for the text editor... I can see this
> being implemented very quickly using TinyMCE. I can see merits to both
> starting from scratch or building on top of that...
>
> What do you guys think?
In general, *I* think if the code is good and it's GNU/AGPL-compatible
it should be OK
and it would be better to avoid reinvent the wheel.

In particular, I don't know if TinyMCE (GNU/LGPL) is compatible with GNU/AGPL.



--
Aldo "xoen" Giambelluca <xoen at xoen.org>

Reply | Threaded
Open this post in threaded view
|

Suggestions

Robin Appelman
We don't actually have to worry about TinyMCE, some other guys already
implemented an odf viewer/editor (editing thing not quite done) in
pure javascript, we will probably start using that. And for
collaborative editing on the same document we will probably let git or
something do the merging between 2 odf files, so that should work with
both people using the webfrontend and people using
webdav+koffice/oo.org.

As for that list which I don't know how to quote in gmail :), most
parts are either already being worked on or in the schedule, and the
other ones are certainly good ideas

On Thu, Jul 8, 2010 at 16:58, Aldo "xoen" Giambelluca <xoen at xoen.org> wrote:

> 2010/7/8 Kenny Coyle <kenny at heloo.net>:
>> I'm quite new to working with OwnCloud (and hoping to develop where I can).
>>
>> Was there ever a decision made on whether to develop everything from
>> scratch, or is it OK to use current open source code inside ownCloud.
>>
>> The reason I ask is primarilly for the text editor... I can see this
>> being implemented very quickly using TinyMCE. I can see merits to both
>> starting from scratch or building on top of that...
>>
>> What do you guys think?
> In general, *I* think if the code is good and it's GNU/AGPL-compatible
> it should be OK
> and it would be better to avoid reinvent the wheel.
>
> In particular, I don't know if TinyMCE (GNU/LGPL) is compatible with GNU/AGPL.
>
>
>
> --
> Aldo "xoen" Giambelluca <xoen at xoen.org>
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>



--
Making the web a weirder place, one mail at a time

Reply | Threaded
Open this post in threaded view
|

Suggestions

Aldo "xoen" Giambelluca
2010/7/8 Robin Appelman <icewind1991 at gmail.com>:
> We don't actually have to worry about TinyMCE, some other guys already
> implemented an odf viewer/editor (editing thing not quite done) in
> pure javascript, we will probably start using that.
An ODF viewer/editor in JavaScript?! Cool!

> And for collaborative editing on the same document we will probably let
> git or something do the merging between 2 odf files, so that should work
> with both people using the webfrontend and people using webdav+koffice/oo.org.
Maybe he meant realtime collaborative editing and probably for this Git
is not the right tool.



--
Aldo "xoen" Giambelluca <xoen at xoen.org>

Reply | Threaded
Open this post in threaded view
|

Suggestions

Hans Bakker
Realtime collaborative editing would indeed be cool and could be implemented
by the solutions I mentioned in my previous mail today.

2010/7/8 Aldo "xoen" Giambelluca <xoen at xoen.org>

> 2010/7/8 Robin Appelman <icewind1991 at gmail.com>:
> > We don't actually have to worry about TinyMCE, some other guys already
> > implemented an odf viewer/editor (editing thing not quite done) in
> > pure javascript, we will probably start using that.
> An ODF viewer/editor in JavaScript?! Cool!
>
> > And for collaborative editing on the same document we will probably let
> > git or something do the merging between 2 odf files, so that should work
> > with both people using the webfrontend and people using webdav+koffice/
> oo.org.
> Maybe he meant realtime collaborative editing and probably for this Git
> is not the right tool.
>
>
>
> --
> Aldo "xoen" Giambelluca <xoen at xoen.org>
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/owncloud/attachments/20100708/965218bb/attachment.htm 

Reply | Threaded
Open this post in threaded view
|

Suggestions

Andrei Nistor
In reply to this post by Robin Appelman
On Thursday 08 July 2010 19:56:27 Robin Appelman wrote:
> We don't actually have to worry about TinyMCE, some other guys already
> implemented an odf viewer/editor (editing thing not quite done) in
> pure javascript, we will probably start using that.

Is ofwebkit the implementation you're talking about?
http://kdedevelopers.org/node/4253

> And for
> collaborative editing on the same document we will probably let git or
> something do the merging between 2 odf files, so that should work with
> both people using the webfrontend and people using
> webdav+koffice/oo.org.

I don't think git is the right tool for realtime collaborative editing. I
would suggest implementing the infinote protocol [0], which would make it
compatible with kobby[1] and gobby[2]. I don't know if it's feasible to
implement this in PHP as I'm not really a PHP programmer, but if it's possible
it would be really nice.

[0] http://gobby.0x539.de/trac/wiki/Infinote/Protocol
[1] http://kobby.greghaynes.net/
[2] http://gobby.0x539.de/trac/

Reply | Threaded
Open this post in threaded view
|

Suggestions

Robin Appelman
On Thu, Jul 8, 2010 at 19:31, Andrei Nistor <coder.tux at ceata.org> wrote:
> On Thursday 08 July 2010 19:56:27 Robin Appelman wrote:
>> We don't actually have to worry about TinyMCE, some other guys already
>> implemented an odf viewer/editor (editing thing not quite done) in
>> pure javascript, we will probably start using that.
>
> Is ofwebkit the implementation you're talking about?
> http://kdedevelopers.org/node/4253
Yes, I saw a short presentation on it today, seems to work nice already

>
>> And for
>> collaborative editing on the same document we will probably let git or
>> something do the merging between 2 odf files, so that should work with
>> both people using the webfrontend and people using
>> webdav+koffice/oo.org.
>
> I don't think git is the right tool for realtime collaborative editing. I
> would suggest implementing the infinote protocol [0], which would make it
> compatible with kobby[1] and gobby[2]. I don't know if it's feasible to
> implement this in PHP as I'm not really a PHP programmer, but if it's possible
> it would be really nice.
Yes it would be really nice, but the last time I looked at it the
documentation was incomplete and the protocol seems complicated, so it
won't be an easy task.

webODF+git will do for near-realtime simulair to gdocs

Reply | Threaded
Open this post in threaded view
|

Suggestions

Andrei Nistor
In reply to this post by Andrei Nistor
On Thursday 08 July 2010 20:31:32 Andrei Nistor wrote:
> I don't think git is the right tool for realtime collaborative editing. I
> would suggest implementing the infinote protocol [0], which would make it
> compatible with kobby[1] and gobby[2]. I don't know if it's feasible to
> implement this in PHP as I'm not really a PHP programmer, but if it's
> possible it would be really nice.
>
Further digging got me to the original specification for the infinote protocol
[3] and a JavaScript implementation released under the MIT license [4]. The
MIT license is compatible with the GPL, but I don't know if it's also
compatible with the AGPL. Maybe someone knows Adriaan de Groot from the kde-
legal team and could ask him to shed some light on the various licenses
compatibility with the AGPL.

> [0] http://gobby.0x539.de/trac/wiki/Infinote/Protocol
> [1] http://kobby.greghaynes.net/
> [2] http://gobby.0x539.de/trac/
[3] http://infinote.org/
[4] http://jinfinote.com/

Reply | Threaded
Open this post in threaded view
|

Suggestions

Robin Appelman
I might ask him if I see him tomorrow, I believe he's on akademy.

but for infinote the problem really is the server, the current one is
c(++)? so no use if we want to use php for deployability

On Thu, Jul 8, 2010 at 19:48, Andrei Nistor <coder.tux at ceata.org> wrote:

> On Thursday 08 July 2010 20:31:32 Andrei Nistor wrote:
>> I don't think git is the right tool for realtime collaborative editing. I
>> would suggest implementing the infinote protocol [0], which would make it
>> compatible with kobby[1] and gobby[2]. I don't know if it's feasible to
>> implement this in PHP as I'm not really a PHP programmer, but if it's
>> possible it would be really nice.
>>
> Further digging got me to the original specification for the infinote protocol
> [3] and a JavaScript implementation released under the MIT license [4]. The
> MIT license is compatible with the GPL, but I don't know if it's also
> compatible with the AGPL. Maybe someone knows Adriaan de Groot from the kde-
> legal team and could ask him to shed some light on the various licenses
> compatibility with the AGPL.
>
>> [0] http://gobby.0x539.de/trac/wiki/Infinote/Protocol
>> [1] http://kobby.greghaynes.net/
>> [2] http://gobby.0x539.de/trac/
> [3] http://infinote.org/
> [4] http://jinfinote.com/
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>



--
Making the web a weirder place, one mail at a time

Reply | Threaded
Open this post in threaded view
|

Suggestions

Jos Poortvliet
In reply to this post by Hans Bakker
On Thursday 08 July 2010 13:34:23 Hans Bakker wrote:
> It would also be nice if people could work together on the same document.
> The web frontend to this could be integrated with ownCloud while an optional
> server could host the simultaneous access. There are several open source
> solutions for this like etherpad <http://code.google.com/p/etherpad/> and
> Infinote <http://infinote.org/>. Jinfinote <http://www.jinfinote.com/>is a
> web frontend to an Infinote server like
> Infinoted<http://gobby.0x539.de/trac/wiki/Infinote/Infinoted>.
> The nice thing of Infinote is that there are also desktop clients for it
> like Kobby <http://kobby.greghaynes.net/home>.

Yep, and the KOffice peeps are working on this too - should certainly be taken into consideration ;-)

> Kind regards,
>
> Hans Bakker
>
> 2010/7/8 cenourinha gmail <webtuga at gmail.com>
>
> > Hi there, i have some suggestions to make.
> >
> > - Multi-user control;
> > - Read/write Permissions;
> > - Code/Text editor web based for .txt, .html, and other file types
> > - Music/Video Player for multimedia files
> > - Space limitations (great for web hosting providers who want to provide
> > web hosting backup solutions with ownCloud)
> > - Multi-language interface
> >
> > Regards,
> > Teot?nio Ricardo
> > WebTuga, Unipessoal Lda
> > http://www.webtuga.pt
> > _______________________________________________
> > Owncloud mailing list
> > Owncloud at kde.org
> > https://mail.kde.org/mailman/listinfo/owncloud
> >
>

Reply | Threaded
Open this post in threaded view
|

Suggestions

Jos Poortvliet
In reply to this post by Robin Appelman
On Thursday 08 July 2010 20:02:11 Robin Appelman wrote:
> I might ask him if I see him tomorrow, I believe he's on akademy.
>
> but for infinote the problem really is the server, the current one is
> c(++)? so no use if we want to use php for deployability

See if you guys can talk to the KOffice ppl about this - besides the java ODF tool they're also talking about this and probably have opinions on what/how when it comes to collaborative editing ;-)
 

> On Thu, Jul 8, 2010 at 19:48, Andrei Nistor <coder.tux at ceata.org> wrote:
> > On Thursday 08 July 2010 20:31:32 Andrei Nistor wrote:
> >> I don't think git is the right tool for realtime collaborative editing. I
> >> would suggest implementing the infinote protocol [0], which would make it
> >> compatible with kobby[1] and gobby[2]. I don't know if it's feasible to
> >> implement this in PHP as I'm not really a PHP programmer, but if it's
> >> possible it would be really nice.
> >>
> > Further digging got me to the original specification for the infinote protocol
> > [3] and a JavaScript implementation released under the MIT license [4]. The
> > MIT license is compatible with the GPL, but I don't know if it's also
> > compatible with the AGPL. Maybe someone knows Adriaan de Groot from the kde-
> > legal team and could ask him to shed some light on the various licenses
> > compatibility with the AGPL.
> >
> >> [0] http://gobby.0x539.de/trac/wiki/Infinote/Protocol
> >> [1] http://kobby.greghaynes.net/
> >> [2] http://gobby.0x539.de/trac/
> > [3] http://infinote.org/
> > [4] http://jinfinote.com/
> > _______________________________________________
> > Owncloud mailing list
> > Owncloud at kde.org
> > https://mail.kde.org/mailman/listinfo/owncloud
> >
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Suggestions

Pierre Stirnweiss
Hi,

I am a KOffice developer, who intend to implement collaborative editing at
some point in KOffice. For now I am doing change tracking.

I agree that GIT is not the way to go for real time collaborative editing.
When speaking of "real time" collaborative editing, we are really talking
about synchronous editing. The problem with several people editing THE same
document at the same time  is concurrent edits. Two ways exists to handle
this:

- the pessimistic approach: real concurrent editing is not allowed. It means
that each editor actually has a lock on the document (or a part of it).
Before the lock is passed, the documents are synchronised.  This ensures
that no incoherence are possible between the different editors. It usually
is implemented by means of a token system. The main advantage of this system
is that the state of each local replica of the document is guaranteed to be
the same before every editing action. there is no risk of divergence between
the different editors. The main drawback of this approach is latency. Since
every user needs to wait for the token for his editing action to happen, the
UI can become really unresponsive if there is a high latency between every
workstation (due to network lag/ high number of users,...).

- the optimistic approach: every editing action is applied locally straight
away and broadcasted to the other editors. Here we broadcast the editing
action ("insert 'a' at pos 3"), not a diff of states (-abc;+abac). The
actions received from the other editors are then transformed by the help of
algorithm so they match the local state of the document replica. The
advantage of this approach is that the editing keeps being responsive no
matter what latency or number of users we have on the network. The main
drawback is that consistency of the several replicas is not guaranteed. None
of the current algorithm I know of can guaranty consistency (for more on
this subject, search for "collaborative editing and operational transform"
in google scholar). Furthermore, the current algorithm are pretty good when
it comes to insert/delete of an atomic piece of text at a certain position.
Operations working on a range are not properly handled by the current
algorithm (that counts for formatting, or deleting a non atomic piece of
text like a word).

Using Git for this would only be possible in the case of the pessimistic
approach because a diff of state only makes sense when the states are
guaranteed to match. And even in that case a broadcast of the actual editing
action is probably cheaper.


One of my goal is indeed to implement collaborative editing in KOffice.
However, I'd like to implement it so that particular protocols are backends
to it.
Infininote is actually two things in one:
- a communication protocol, of which several different flavour exist:
server/client architecture (infininote, jupiter,...) or distributed. For
this I hope to be able to rely on KDE infrastructure (Telepathy?), but
haven't looked very deep into this yet.
- a real time editing algorithm using the optimistic approach, of which
several different flavour exist: for infininote it is the adOPTed algorithm.
Several others have been developed since to address quite a few of its
limitations. Most are based on the OPerational Transformation (OPT) design,
a couple have moved away from it (once again google scholar is your friend
there, also look for "tombstone" with the aforementioned search terms).

As for the when it comes to form, the main problem here is manpower. I have
a pretty good idea of what I'd like to implement. However, I am still not
finished with change tracking in KOffice (which, as opposed to real time
collaborative editing, is specified by ODF).

Pierre


On Tue, Jul 13, 2010 at 10:08 PM, Jos Poortvliet <jospoortvliet at gmail.com>wrote:

> On Thursday 08 July 2010 20:02:11 Robin Appelman wrote:
> > I might ask him if I see him tomorrow, I believe he's on akademy.
> >
> > but for infinote the problem really is the server, the current one is
> > c(++)? so no use if we want to use php for deployability
>
> See if you guys can talk to the KOffice ppl about this - besides the java
> ODF tool they're also talking about this and probably have opinions on
> what/how when it comes to collaborative editing ;-)
>
> > On Thu, Jul 8, 2010 at 19:48, Andrei Nistor <coder.tux at ceata.org> wrote:
> > > On Thursday 08 July 2010 20:31:32 Andrei Nistor wrote:
> > >> I don't think git is the right tool for realtime collaborative
> editing. I
> > >> would suggest implementing the infinote protocol [0], which would make
> it
> > >> compatible with kobby[1] and gobby[2]. I don't know if it's feasible
> to
> > >> implement this in PHP as I'm not really a PHP programmer, but if it's
> > >> possible it would be really nice.
> > >>
> > > Further digging got me to the original specification for the infinote
> protocol
> > > [3] and a JavaScript implementation released under the MIT license [4].
> The
> > > MIT license is compatible with the GPL, but I don't know if it's also
> > > compatible with the AGPL. Maybe someone knows Adriaan de Groot from the
> kde-
> > > legal team and could ask him to shed some light on the various licenses
> > > compatibility with the AGPL.
> > >
> > >> [0] http://gobby.0x539.de/trac/wiki/Infinote/Protocol
> > >> [1] http://kobby.greghaynes.net/
> > >> [2] http://gobby.0x539.de/trac/
> > > [3] http://infinote.org/
> > > [4] http://jinfinote.com/
> > > _______________________________________________
> > > Owncloud mailing list
> > > Owncloud at kde.org
> > > https://mail.kde.org/mailman/listinfo/owncloud
> > >
> >
> >
> >
> >
> _______________________________________________
> koffice-devel mailing list
> koffice-devel at kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/owncloud/attachments/20100714/5aa2102c/attachment.htm 

Reply | Threaded
Open this post in threaded view
|

Suggestions

Mario Fux
Good morning

BTW: Pierre, how is your work related to the "Collaborative editing" in
FreOffice?
http://talk.maemo.org/showthread.php?t=58342

thx for all your work
Mario

Reply | Threaded
Open this post in threaded view
|

Suggestions

Pierre Stirnweiss
it isn't. I have not started working on collaborative editing in koffice yet
(apart from reading a lot about it). I need to finish the change tracking
first. I have looked at the FreOffice review request, and have a question
regarding concurrency which awaits for an answer. My intention is however to
provide a broader range of collaboration framework.

Pierre



On Wed, Jul 14, 2010 at 6:53 PM, Mario Fux <kde-ml at unormal.org> wrote:

> Good morning
>
> BTW: Pierre, how is your work related to the "Collaborative editing" in
> FreOffice?
> http://talk.maemo.org/showthread.php?t=58342
>
> thx for all your work
> Mario
> _______________________________________________
> koffice-devel mailing list
> koffice-devel at kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/owncloud/attachments/20100714/3ba588db/attachment-0001.htm 

Reply | Threaded
Open this post in threaded view
|

Suggestions

iberlynx
In reply to this post by Pierre Stirnweiss
Hi,

you say git is not the way to go because you only consider it in the pessimistic approach. But have you thought of using git or some similarly powerful diff engine with an optimistic approach?

Let me give you my proposal:
Every user action be it a single character change or a block change or a formatting change is automatically git-committed and git-pushed to the other users, which would automatically git-merge the changes as git does so well. So no locking would be required, hence no latency problem.
(This would additionally solve the problem you stated with non atomic changes!)
The only obstacle that I foresee is that IIRC git doesn't merge changes on the same line, but I'm sure that there's a way to tailor git's algorithm for this specific use-case!

Am I just being my usual self, and this is a crazy idea? Or does it make sense to you as well?


On Wednesday 14 July 2010 10:17:47 Pierre Stirnweiss wrote:

> Hi,
>
> I am a KOffice developer, who intend to implement collaborative editing at
> some point in KOffice. For now I am doing change tracking.
>
> I agree that GIT is not the way to go for real time collaborative editing.
> When speaking of "real time" collaborative editing, we are really talking
> about synchronous editing. The problem with several people editing THE same
> document at the same time  is concurrent edits. Two ways exists to handle
> this:
>
> - the pessimistic approach: real concurrent editing is not allowed. It means
> that each editor actually has a lock on the document (or a part of it).
> Before the lock is passed, the documents are synchronised.  This ensures
> that no incoherence are possible between the different editors. It usually
> is implemented by means of a token system. The main advantage of this system
> is that the state of each local replica of the document is guaranteed to be
> the same before every editing action. there is no risk of divergence between
> the different editors. The main drawback of this approach is latency. Since
> every user needs to wait for the token for his editing action to happen, the
> UI can become really unresponsive if there is a high latency between every
> workstation (due to network lag/ high number of users,...).
>
> - the optimistic approach: every editing action is applied locally straight
> away and broadcasted to the other editors. Here we broadcast the editing
> action ("insert 'a' at pos 3"), not a diff of states (-abc;+abac). The
> actions received from the other editors are then transformed by the help of
> algorithm so they match the local state of the document replica. The
> advantage of this approach is that the editing keeps being responsive no
> matter what latency or number of users we have on the network. The main
> drawback is that consistency of the several replicas is not guaranteed. None
> of the current algorithm I know of can guaranty consistency (for more on
> this subject, search for "collaborative editing and operational transform"
> in google scholar). Furthermore, the current algorithm are pretty good when
> it comes to insert/delete of an atomic piece of text at a certain position.
> Operations working on a range are not properly handled by the current
> algorithm (that counts for formatting, or deleting a non atomic piece of
> text like a word).
>
> Using Git for this would only be possible in the case of the pessimistic
> approach because a diff of state only makes sense when the states are
> guaranteed to match. And even in that case a broadcast of the actual editing
> action is probably cheaper.
>
>
> One of my goal is indeed to implement collaborative editing in KOffice.
> However, I'd like to implement it so that particular protocols are backends
> to it.
> Infininote is actually two things in one:
> - a communication protocol, of which several different flavour exist:
> server/client architecture (infininote, jupiter,...) or distributed. For
> this I hope to be able to rely on KDE infrastructure (Telepathy?), but
> haven't looked very deep into this yet.
> - a real time editing algorithm using the optimistic approach, of which
> several different flavour exist: for infininote it is the adOPTed algorithm.
> Several others have been developed since to address quite a few of its
> limitations. Most are based on the OPerational Transformation (OPT) design,
> a couple have moved away from it (once again google scholar is your friend
> there, also look for "tombstone" with the aforementioned search terms).
>
> As for the when it comes to form, the main problem here is manpower. I have
> a pretty good idea of what I'd like to implement. However, I am still not
> finished with change tracking in KOffice (which, as opposed to real time
> collaborative editing, is specified by ODF).
>
> Pierre
>
>
> On Tue, Jul 13, 2010 at 10:08 PM, Jos Poortvliet <jospoortvliet at gmail.com>wrote:
>
> > On Thursday 08 July 2010 20:02:11 Robin Appelman wrote:
> > > I might ask him if I see him tomorrow, I believe he's on akademy.
> > >
> > > but for infinote the problem really is the server, the current one is
> > > c(++)? so no use if we want to use php for deployability
> >
> > See if you guys can talk to the KOffice ppl about this - besides the java
> > ODF tool they're also talking about this and probably have opinions on
> > what/how when it comes to collaborative editing ;-)
> >
> > > On Thu, Jul 8, 2010 at 19:48, Andrei Nistor <coder.tux at ceata.org> wrote:
> > > > On Thursday 08 July 2010 20:31:32 Andrei Nistor wrote:
> > > >> I don't think git is the right tool for realtime collaborative
> > editing. I
> > > >> would suggest implementing the infinote protocol [0], which would make
> > it
> > > >> compatible with kobby[1] and gobby[2]. I don't know if it's feasible
> > to
> > > >> implement this in PHP as I'm not really a PHP programmer, but if it's
> > > >> possible it would be really nice.
> > > >>
> > > > Further digging got me to the original specification for the infinote
> > protocol
> > > > [3] and a JavaScript implementation released under the MIT license [4].
> > The
> > > > MIT license is compatible with the GPL, but I don't know if it's also
> > > > compatible with the AGPL. Maybe someone knows Adriaan de Groot from the
> > kde-
> > > > legal team and could ask him to shed some light on the various licenses
> > > > compatibility with the AGPL.
> > > >
> > > >> [0] http://gobby.0x539.de/trac/wiki/Infinote/Protocol
> > > >> [1] http://kobby.greghaynes.net/
> > > >> [2] http://gobby.0x539.de/trac/
> > > > [3] http://infinote.org/
> > > > [4] http://jinfinote.com/
> > > > _______________________________________________
> > > > Owncloud mailing list
> > > > Owncloud at kde.org
> > > > https://mail.kde.org/mailman/listinfo/owncloud
> > > >
> > >
> > >
> > >
> > >
> > _______________________________________________
> > koffice-devel mailing list
> > koffice-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/koffice-devel
> >
>


Reply | Threaded
Open this post in threaded view
|

Suggestions

Jaroslaw Staniek
On 14 July 2010 22:43, iberlynx <iberlynx at lavabit.com> wrote:

> Hi,
>
> you say git is not the way to go because you only consider it in the pessimistic approach. But have you thought of using git or some similarly powerful diff engine with an optimistic approach?
>
> Let me give you my proposal:
> Every user action be it a single character change or a block change or a formatting change is automatically git-committed and git-pushed to the other users, which would automatically git-merge the changes as git does so well. So no locking would be required, hence no latency problem.
> (This would additionally solve the problem you stated with non atomic changes!)
> The only obstacle that I foresee is that IIRC git doesn't merge changes on the same line, but I'm sure that there's a way to tailor git's algorithm for this specific use-case!
>
> Am I just being my usual self, and this is a crazy idea? Or does it make sense to you as well?

Hi;
Just a though:
Do we need as heavy waepon as git for this simple non-conflicing case?
As you admitted, nontrivial (real) cases need extensions/hooks to git,
the same that would also be needed for other version control tools. Is
there anything special about git that helps in collaborative editing
of documents?

Regarding extensions for merging at text level, please note that git
or similar tools are for source code, character-based media; for
structured media even merging tables is nontrivial in general case.
IMHO it's worth to consider locking feature at local level (paragraph
or table) than accepting any edits and then trying to merge.

--
regards / pozdrawiam, Jaroslaw Staniek
?http://www.linkedin.com/in/jstaniek
?Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
?KDE Software Development Platform on MS Windows (http://windows.kde.org)

12