Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda sa...@lyx.org wrote:
 Marcelo Galv?o Póvoa wrote:
 Please check the description I just sent. These side effects of
 editing would be handled normally at the internal representation
 level, the data to be sent are the changes to the textual
 representation (ie, modifications that would appear at the LyX file).

 Just to check whether I understood your concept - you basically want to
 synchronize the internal lyx structures between peers by using .lyx diffs as
 transport layer, while hoping that full reconstruction from .lyx diff snippet
 into lyx internal structure is possible, right?


Exactly, the hoping part is where the GSoC comes in.

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Marcelo Galv?o Póvoa wrote:
  Just to check whether I understood your concept - you basically want to
  synchronize the internal lyx structures between peers by using .lyx diffs as
  transport layer, while hoping that full reconstruction from .lyx diff 
  snippet
  into lyx internal structure is possible, right?
 
 
 Exactly, the hoping part is where the GSoC comes in.

This is unfortunately bad news. Internal structure change - .lyx snippet is 
lossy
transformation. There is lot of intelligence hidden in lfun dispatch machinery
hidden on the local side that changes internal structure but won't be visible
in .lyx diffs (various computations in my previous mail).

To reconstruct these you either need to 
a) reconstruct exact lfun call's on remote side or
b) find way how to directly change internal structures from snippets
   (and reproducing what lfuns do anyway).

I expect that a) implies lot of very fragile guess-work on remote side and to
get it it would be much easier to actually directly send lfun commands so 
I expect you mean b).

b) Implies changes in both lfun dispatch machinery and loading routines of .lyx
file, because we need only single place where these computations happen
(maintenance reasons).
Can you shed more light how do you want to do this because at the moment it
seems to be quite serious surgery in lyx guts prone to errors leading to 
dataloss
bugs (the worst ones).

Pavel

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 02/05/13 12:03, Marcelo Galvão Póvoa wrote:
 On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda sa...@lyx.org wrote:
 Marcelo Galv?o Póvoa wrote:
 Just to check whether I understood your concept - you basically want to
 synchronize the internal lyx structures between peers by using .lyx diffs as
 transport layer, while hoping that full reconstruction from .lyx diff snippet
 into lyx internal structure is possible, right?

 
 Exactly, the hoping part is where the GSoC comes in.

As an immediate concern, adding to Pavel's ones, I have to say that I'm not
so sure that merging different edits on the .lyx file level, very much like a
version control system would do in presence of concurrent commits, would
actually be guaranteed to produce a consistent/legal .lyx file.

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 As an immediate concern, adding to Pavel's ones, I have to say that I'm not
 so sure that merging different edits on the .lyx file level, very much like a
 version control system would do in presence of concurrent commits, would
 actually be guaranteed to produce a consistent/legal .lyx file.

You need a representation that makes merging feasible.  A typical
3-way diff/merge like, say, git uses, cannot produce legal C, XML, ...
by itself.  It is possible to build 3-way diff/merge that can produce
valid merged output for specific syntaxes.  In particular it should be
possible for XML and other nested/parse-tree-like formats.  I believe
there are some non-free, proprietary XML 3-way diff/merge tools that
don't suck, but they are non-free and I've not tried them.

If this is the tack you want to follow for collaborative distributed
LyX editing then I think it'd be best to write a 3-way diff/merge for
.lyx or some representation of it.  A 3-way diff/merge for XML would
also be useful in this respect, though it'd bring in more bloat, but
it'd also be incredibly useful in general.

Nico
--

Re: GSoC 2013: Interactive LyX

[Richard Heck]

On 05/02/2013 03:01 PM, Tommaso Cucinotta wrote:

On 02/05/13 12:03, Marcelo Galvão Póvoa wrote:

On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda sa...@lyx.org wrote:

Marcelo Galv?o Póvoa wrote:
Just to check whether I understood your concept - you basically want to 
synchronize the internal lyx structures between peers by using .lyx diffs as 
transport layer, while hoping that full reconstruction from .lyx diff snippet 
into lyx internal structure is possible, right?


Exactly, the hoping part is where the GSoC comes in.

As an immediate concern, adding to Pavel's ones, I have to say that I'm not so 
sure that merging different edits on the .lyx file level, very much like a 
version control system would do in presence of concurrent commits, would 
actually be guaranteed to produce a consistent/legal .lyx file.


I'm fairly sure it would frequently NOT produce a legal file.

Richard

Re: GSoC 2013: Interactive LyX

[Richard Heck]

On 05/02/2013 03:16 PM, Nico Williams wrote:

On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta tomm...@lyx.org wrote:

As an immediate concern, adding to Pavel's ones, I have to say that I'm not
so sure that merging different edits on the .lyx file level, very much like a
version control system would do in presence of concurrent commits, would
actually be guaranteed to produce a consistent/legal .lyx file.

You need a representation that makes merging feasible.  A typical
3-way diff/merge like, say, git uses, cannot produce legal C, XML, ...
by itself.  It is possible to build 3-way diff/merge that can produce
valid merged output for specific syntaxes.  In particular it should be
possible for XML and other nested/parse-tree-like formats.  I believe
there are some non-free, proprietary XML 3-way diff/merge tools that
don't suck, but they are non-free and I've not tried them.

If this is the tack you want to follow for collaborative distributed
LyX editing then I think it'd be best to write a 3-way diff/merge for
.lyx or some representation of it.  A 3-way diff/merge for XML would
also be useful in this respect, though it'd bring in more bloat, but
it'd also be incredibly useful in general.


And if we went to an XML format.

Richard

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Thu, May 2, 2013 at 2:22 PM, Richard Heck rgh...@lyx.org wrote:
 On 05/02/2013 03:16 PM, Nico Williams wrote:

 On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta tomm...@lyx.org wrote:

 As an immediate concern, adding to Pavel's ones, I have to say that I'm
 not
 so sure that merging different edits on the .lyx file level, very much
 like a
 version control system would do in presence of concurrent commits, would
 actually be guaranteed to produce a consistent/legal .lyx file.

 You need a representation that makes merging feasible.  A typical
 3-way diff/merge like, say, git uses, cannot produce legal C, XML, ...
 by itself.  It is possible to build 3-way diff/merge that can produce
 valid merged output for specific syntaxes.  In particular it should be
 possible for XML and other nested/parse-tree-like formats.  I believe
 there are some non-free, proprietary XML 3-way diff/merge tools that
 don't suck, but they are non-free and I've not tried them.

 If this is the tack you want to follow for collaborative distributed
 LyX editing then I think it'd be best to write a 3-way diff/merge for
 .lyx or some representation of it.  A 3-way diff/merge for XML would
 also be useful in this respect, though it'd bring in more bloat, but
 it'd also be incredibly useful in general.


 And if we went to an XML format.

:)

I took a look at the *import* side and I think it wouldn't be hard to
read XML in LyX.  I haven't looked a the save side, but I suspect it's
not terribly hard there either.  The biggest problem w.r.t. saving are
the places where LyX does not stick to strict containership (and which
I deal with in my lyx2xml script by auto-closing (and sometimes
re-opening) tags as implied by the .lyx.  For example, \series and
friends.  This can be dealt with in XML saving code like I do in
lyx2xml, or by changing the handling of such tokens to always follow
strict containership.

OTOH, changing the internals so that LyX always deals with XML
objects, as if .lyx were a DOM, is probably order sof magnitude more
work than making LyX open/save XML.

In fact, a GSoC project to load/save XML would probably be quite useful.

Nico
--

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 02/05/13 20:30, Nico Williams wrote:
 In fact, a GSoC project to load/save XML would probably be quite useful.

I was just about to suggest you to add such proposal, as it's a long standing 
issue. It's quite late now, but who knows perhaps a student takes the chance 
:-).

Just, I'd address this as independent of interactive LyX.

As of now, after the discussion I've seen, I'm still in favour of the LFUN 
exchange, after all, with some fix-up of the editing point, or range points (in 
case of operations on regions). Plus, some re-send of the overall paragraph or 
document in corner cases when things are detected/suspected to have screwed up, 
with auto-triggering of the Compare Document feature to sort out possible 
conflicts. But, keep things simple in a first round/milestone, w/out pretending 
too much, e.g., prevent conflicts rather than having to sort them out, then 
adding support for more complex and more conflicting scenarios along the way. 
At least, we have a set of incremental features and we can stop at any time 
with something usable.

Also, I think it would be nice to have (optionally) a history panel allowing to 
track the various revisions/edits received by the other editor(s), as well as 
ours, in order to keep track of what each one has been doing. Of course, we 
don't want to track each and every char insertion, so there must be some 
grouping logic here to show only major edit points.

T.

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Thu, May 2, 2013 at 1:36 PM, Pavel Sanda sa...@lyx.org wrote:
 Marcelo Galv?o Póvoa wrote:
  Just to check whether I understood your concept - you basically want to
  synchronize the internal lyx structures between peers by using .lyx diffs 
  as
  transport layer, while hoping that full reconstruction from .lyx diff 
  snippet
  into lyx internal structure is possible, right?
 

 Exactly, the hoping part is where the GSoC comes in.

 This is unfortunately bad news. Internal structure change - .lyx snippet is 
 lossy
 transformation. There is lot of intelligence hidden in lfun dispatch machinery
 hidden on the local side that changes internal structure but won't be visible
 in .lyx diffs (various computations in my previous mail).


I understand that there may be side effects that should be taken into
account when reconstructing internal LyX structure from a .lyx
snippet. Section numbering may have to be recomputed as you said
earlier. But I don't see this transformation as lossy meaning that
unrecoverable information is being discarded, simply because this is
how a .lyx file is saved.

 To reconstruct these you either need to
 a) reconstruct exact lfun call's on remote side or
 b) find way how to directly change internal structures from snippets
(and reproducing what lfuns do anyway).

 I expect that a) implies lot of very fragile guess-work on remote side and to
 get it it would be much easier to actually directly send lfun commands so
 I expect you mean b).

 b) Implies changes in both lfun dispatch machinery and loading routines of 
 .lyx
 file, because we need only single place where these computations happen
 (maintenance reasons).
 Can you shed more light how do you want to do this because at the moment it
 seems to be quite serious surgery in lyx guts prone to errors leading to 
 dataloss
 bugs (the worst ones).


Yes, I mean b). I don't know anything yet about how these internal
routines are structured, but I hope that you could refactor them to be
able to convert snippets of a .lyx file to internal objects and also
perform housekeeping (the side effects I mentioned above) where
needed. If this can't be done at all, then this approach is probably
invalid.

Marcelo

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Marcelo Galv?o Póvoa wrote:
 earlier. But I don't see this transformation as lossy meaning that
 unrecoverable information is being discarded, simply because this is
 how a .lyx file is saved.

Yep, what I meant - it's lossy unless you reload whole .lyx file (you want to
do that after each keypress?) or replicate what's going on in dispatch
machinery (untrivial).

My impression is that you propose .lyx snippet solution because you have ready
made simple-text-to-simple-text protocol from other project, not because it's
good from lyx POV. I.e. you propose using solved 3d while getting into unsolved
3b, 3c, perhaps 3a (see below).

I can be wrong but than you need to be substantially more detailed what you
will do with with the code architecture so one can evaluate it.

 needed. If this can't be done at all, then this approach is probably
 invalid.

My guess is that any .lyx snippet load and its integration into internal
structures can be quickly done to 95%, then you spent 2 more years on those 5%
never really getting it 100% and from time to time screwing up users document. 

Time for proposal is almost gone, so my summary is

A)
Possible routes for data exchange is:

1. Protocol based on lfun passing.
   Works only ack-ack change basis, no one knows whether net latency allow 
this. (i)
   Data consitency and peers synchro should be safe in this scenario. (ii)
   Needs surgery is cursor stuff. (iii)
   Perhaps we need to disable some editing actions (inserting external 
material...)(iv).
 
2. Protocol based on undo/redo actions passing.
   This idea came to me during the thread. Because cursor position is saved
   in redo actions it's well possible that (iii) can be avoided to large part.
   (i),(ii) and (iv) are the same here.

3. Protocal based on external data (.lyx,.xml,whatever).
   Much more powerful, allowing bigger net latencies or even users going 
offline,
   connection to VCS etc. If 1/2 is not possible we have perhaps nowhere else 
to go.
   And now the blow:
   It needs surgery in cursor. (a)
   It needs surgery in lfun dispatch mechanism so we don't duplicate code in 
(c). (b)
   It needs surgery in .lyx loading (or whatever import we choose). (c)
   It needs studying merging protocols. (d)

   Each of (a),(b),(c) itself will be hard for newcomer coder, not to speak
   about people who seem to lack lyx power user experience (it's very difficult
   to get idea about possible corner cases just by reading the code).
   Whoever reads this find at which camp you are.
   (c) will be especially tough to get right without getting data consistency 
issues.
   
B)
After A) is figured out or work in simplistic conditions like direct ip-ip 
connections
it's time to start thinking how to deal with nat network problems and users 
finding each other. 
Should be generic enough so its simple to add different solutions.
I hope you see why A before B.

Pavel


Next random bit :)
What do we do if some document class or module is missing on the remote side,
not providing environment, charstyle?

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda  wrote:
> Marcelo Galv?o Póvoa wrote:
>> Please check the description I just sent. These side effects of
>> editing would be handled normally at the internal representation
>> level, the data to be sent are the changes to the textual
>> representation (ie, modifications that would appear at the LyX file).
>
> Just to check whether I understood your concept - you basically want to
> synchronize the internal lyx structures between peers by using .lyx diffs as
> transport layer, while hoping that full reconstruction from .lyx diff snippet
> into lyx internal structure is possible, right?
>

Exactly, the "hoping" part is where the GSoC comes in.

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Marcelo Galv?o Póvoa wrote:
> > Just to check whether I understood your concept - you basically want to
> > synchronize the internal lyx structures between peers by using .lyx diffs as
> > transport layer, while hoping that full reconstruction from .lyx diff 
> > snippet
> > into lyx internal structure is possible, right?
> >
> 
> Exactly, the "hoping" part is where the GSoC comes in.

This is unfortunately bad news. Internal structure change -> .lyx snippet is 
lossy
transformation. There is lot of intelligence hidden in lfun dispatch machinery
hidden on the local side that changes internal structure but won't be visible
in .lyx diffs (various "computations" in my previous mail).

To reconstruct these you either need to 
a) reconstruct exact lfun call's on remote side or
b) find way how to directly change internal structures from snippets
   (and reproducing what lfuns do anyway).

I expect that a) implies lot of very fragile guess-work on remote side and to
get it it would be much easier to actually directly send lfun commands so 
I expect you mean b).

b) Implies changes in both lfun dispatch machinery and loading routines of .lyx
file, because we need only single place where these computations happen
(maintenance reasons).
Can you shed more light how do you want to do this because at the moment it
seems to be quite serious surgery in lyx guts prone to errors leading to 
dataloss
bugs (the worst ones).

Pavel

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 02/05/13 12:03, Marcelo Galvão Póvoa wrote:
> On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda  wrote:
>> Marcelo Galv?o Póvoa wrote:
>> Just to check whether I understood your concept - you basically want to
>> synchronize the internal lyx structures between peers by using .lyx diffs as
>> transport layer, while hoping that full reconstruction from .lyx diff snippet
>> into lyx internal structure is possible, right?
>>
> 
> Exactly, the "hoping" part is where the GSoC comes in.

As an immediate concern, adding to Pavel's ones, I have to say that I'm not
so sure that merging different edits on the .lyx file level, very much like a
version control system would do in presence of concurrent commits, would
actually be guaranteed to produce a consistent/legal .lyx file.

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta  wrote:
> As an immediate concern, adding to Pavel's ones, I have to say that I'm not
> so sure that merging different edits on the .lyx file level, very much like a
> version control system would do in presence of concurrent commits, would
> actually be guaranteed to produce a consistent/legal .lyx file.

You need a representation that makes merging feasible.  A typical
3-way diff/merge like, say, git uses, cannot produce legal C, XML, ...
by itself.  It is possible to build 3-way diff/merge that can produce
valid merged output for specific syntaxes.  In particular it should be
possible for XML and other nested/parse-tree-like formats.  I believe
there are some non-free, proprietary XML 3-way diff/merge tools that
don't suck, but they are non-free and I've not tried them.

If this is the tack you want to follow for collaborative distributed
LyX editing then I think it'd be best to write a 3-way diff/merge for
.lyx or some representation of it.  A 3-way diff/merge for XML would
also be useful in this respect, though it'd bring in more bloat, but
it'd also be incredibly useful in general.

Nico
--

Re: GSoC 2013: Interactive LyX

[Richard Heck]

On 05/02/2013 03:01 PM, Tommaso Cucinotta wrote:

On 02/05/13 12:03, Marcelo Galvão Póvoa wrote:

On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda  wrote:

Marcelo Galv?o Póvoa wrote:
Just to check whether I understood your concept - you basically want to 
synchronize the internal lyx structures between peers by using .lyx diffs as 
transport layer, while hoping that full reconstruction from .lyx diff snippet 
into lyx internal structure is possible, right?


Exactly, the "hoping" part is where the GSoC comes in.

As an immediate concern, adding to Pavel's ones, I have to say that I'm not so 
sure that merging different edits on the .lyx file level, very much like a 
version control system would do in presence of concurrent commits, would 
actually be guaranteed to produce a consistent/legal .lyx file.


I'm fairly sure it would frequently NOT produce a legal file.

Richard

Re: GSoC 2013: Interactive LyX

[Richard Heck]

On 05/02/2013 03:16 PM, Nico Williams wrote:

On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta  wrote:

As an immediate concern, adding to Pavel's ones, I have to say that I'm not
so sure that merging different edits on the .lyx file level, very much like a
version control system would do in presence of concurrent commits, would
actually be guaranteed to produce a consistent/legal .lyx file.

You need a representation that makes merging feasible.  A typical
3-way diff/merge like, say, git uses, cannot produce legal C, XML, ...
by itself.  It is possible to build 3-way diff/merge that can produce
valid merged output for specific syntaxes.  In particular it should be
possible for XML and other nested/parse-tree-like formats.  I believe
there are some non-free, proprietary XML 3-way diff/merge tools that
don't suck, but they are non-free and I've not tried them.

If this is the tack you want to follow for collaborative distributed
LyX editing then I think it'd be best to write a 3-way diff/merge for
.lyx or some representation of it.  A 3-way diff/merge for XML would
also be useful in this respect, though it'd bring in more bloat, but
it'd also be incredibly useful in general.


And if we went to an XML format.

Richard

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Thu, May 2, 2013 at 2:22 PM, Richard Heck  wrote:
> On 05/02/2013 03:16 PM, Nico Williams wrote:
>>
>> On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta  wrote:
>>>
>>> As an immediate concern, adding to Pavel's ones, I have to say that I'm
>>> not
>>> so sure that merging different edits on the .lyx file level, very much
>>> like a
>>> version control system would do in presence of concurrent commits, would
>>> actually be guaranteed to produce a consistent/legal .lyx file.
>>
>> You need a representation that makes merging feasible.  A typical
>> 3-way diff/merge like, say, git uses, cannot produce legal C, XML, ...
>> by itself.  It is possible to build 3-way diff/merge that can produce
>> valid merged output for specific syntaxes.  In particular it should be
>> possible for XML and other nested/parse-tree-like formats.  I believe
>> there are some non-free, proprietary XML 3-way diff/merge tools that
>> don't suck, but they are non-free and I've not tried them.
>>
>> If this is the tack you want to follow for collaborative distributed
>> LyX editing then I think it'd be best to write a 3-way diff/merge for
>> .lyx or some representation of it.  A 3-way diff/merge for XML would
>> also be useful in this respect, though it'd bring in more bloat, but
>> it'd also be incredibly useful in general.
>
>
> And if we went to an XML format.

:)

I took a look at the *import* side and I think it wouldn't be hard to
read XML in LyX.  I haven't looked a the save side, but I suspect it's
not terribly hard there either.  The biggest problem w.r.t. saving are
the places where LyX does not stick to strict containership (and which
I deal with in my lyx2xml script by auto-closing (and sometimes
re-opening) tags as implied by the .lyx.  For example, \series and
friends.  This can be dealt with in XML saving code like I do in
lyx2xml, or by changing the handling of such tokens to always follow
strict containership.

OTOH, changing the internals so that LyX always deals with XML
objects, as if .lyx were a DOM, is probably order sof magnitude more
work than making LyX open/save XML.

In fact, a GSoC project to load/save XML would probably be quite useful.

Nico
--

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 02/05/13 20:30, Nico Williams wrote:
> In fact, a GSoC project to load/save XML would probably be quite useful.

I was just about to suggest you to add such proposal, as it's a long standing 
issue. It's quite late now, but who knows perhaps a student takes the chance 
:-).

Just, I'd address this as independent of interactive LyX.

As of now, after the discussion I've seen, I'm still in favour of the LFUN 
exchange, after all, with some fix-up of the editing point, or range points (in 
case of operations on regions). Plus, some re-send of the overall paragraph or 
document in corner cases when things are detected/suspected to have screwed up, 
with auto-triggering of the Compare Document feature to sort out possible 
conflicts. But, keep things simple in a first round/milestone, w/out pretending 
too much, e.g., prevent conflicts rather than having to sort them out, then 
adding support for more complex and more conflicting scenarios along the way. 
At least, we have a set of incremental features and we can stop at any time 
with something usable.

Also, I think it would be nice to have (optionally) a history panel allowing to 
track the various revisions/edits received by the other editor(s), as well as 
ours, in order to keep track of what each one has been doing. Of course, we 
don't want to track each and every char insertion, so there must be some 
grouping logic here to show only major edit points.

T.

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Thu, May 2, 2013 at 1:36 PM, Pavel Sanda  wrote:
> Marcelo Galv?o Póvoa wrote:
>> > Just to check whether I understood your concept - you basically want to
>> > synchronize the internal lyx structures between peers by using .lyx diffs 
>> > as
>> > transport layer, while hoping that full reconstruction from .lyx diff 
>> > snippet
>> > into lyx internal structure is possible, right?
>> >
>>
>> Exactly, the "hoping" part is where the GSoC comes in.
>
> This is unfortunately bad news. Internal structure change -> .lyx snippet is 
> lossy
> transformation. There is lot of intelligence hidden in lfun dispatch machinery
> hidden on the local side that changes internal structure but won't be visible
> in .lyx diffs (various "computations" in my previous mail).
>

I understand that there may be side effects that should be taken into
account when reconstructing internal LyX structure from a .lyx
snippet. Section numbering may have to be recomputed as you said
earlier. But I don't see this transformation as "lossy" meaning that
unrecoverable information is being discarded, simply because this is
how a .lyx file is saved.

> To reconstruct these you either need to
> a) reconstruct exact lfun call's on remote side or
> b) find way how to directly change internal structures from snippets
>(and reproducing what lfuns do anyway).
>
> I expect that a) implies lot of very fragile guess-work on remote side and to
> get it it would be much easier to actually directly send lfun commands so
> I expect you mean b).
>
> b) Implies changes in both lfun dispatch machinery and loading routines of 
> .lyx
> file, because we need only single place where these computations happen
> (maintenance reasons).
> Can you shed more light how do you want to do this because at the moment it
> seems to be quite serious surgery in lyx guts prone to errors leading to 
> dataloss
> bugs (the worst ones).
>

Yes, I mean b). I don't know anything yet about how these internal
routines are structured, but I hope that you could refactor them to be
able to convert snippets of a .lyx file to internal objects and also
perform housekeeping (the side effects I mentioned above) where
needed. If this can't be done at all, then this approach is probably
invalid.

Marcelo

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Marcelo Galv?o Póvoa wrote:
> earlier. But I don't see this transformation as "lossy" meaning that
> unrecoverable information is being discarded, simply because this is
> how a .lyx file is saved.

Yep, what I meant - it's lossy unless you reload whole .lyx file (you want to
do that after each keypress?) or replicate what's going on in dispatch
machinery (untrivial).

My impression is that you propose .lyx snippet solution because you have ready
made simple-text-to-simple-text protocol from other project, not because it's
good from lyx POV. I.e. you propose using solved 3d while getting into unsolved
3b, 3c, perhaps 3a (see below).

I can be wrong but than you need to be substantially more detailed what you
will do with with the code architecture so one can evaluate it.

> needed. If this can't be done at all, then this approach is probably
> invalid.

My guess is that any .lyx snippet load and its integration into internal
structures can be quickly done to 95%, then you spent 2 more years on those 5%
never really getting it 100% and from time to time screwing up users document. 

Time for proposal is almost gone, so my summary is

A)
Possible routes for data exchange is:

1. Protocol based on lfun passing.
   Works only ack-ack change basis, no one knows whether net latency allow 
this. (i)
   Data consitency and peers synchro should be safe in this scenario. (ii)
   Needs surgery is cursor stuff. (iii)
   Perhaps we need to disable some editing actions (inserting external 
material...)(iv).
 
2. Protocol based on undo/redo actions passing.
   This idea came to me during the thread. Because cursor position is saved
   in redo actions it's well possible that (iii) can be avoided to large part.
   (i),(ii) and (iv) are the same here.

3. Protocal based on external data (.lyx,.xml,whatever).
   Much more powerful, allowing bigger net latencies or even users going 
offline,
   connection to VCS etc. If 1/2 is not possible we have perhaps nowhere else 
to go.
   And now the blow:
   It needs surgery in cursor. (a)
   It needs surgery in lfun dispatch mechanism so we don't duplicate code in 
(c). (b)
   It needs surgery in .lyx loading (or whatever import we choose). (c)
   It needs studying merging protocols. (d)

   Each of (a),(b),(c) itself will be hard for newcomer coder, not to speak
   about people who seem to lack lyx power user experience (it's very difficult
   to get idea about possible corner cases just by reading the code).
   Whoever reads this find at which camp you are.
   (c) will be especially tough to get right without getting data consistency 
issues.
   
B)
After A) is figured out or work in simplistic conditions like direct ip<->ip 
connections
it's time to start thinking how to deal with nat network problems and users 
finding each other. 
Should be generic enough so its simple to add different solutions.
I hope you see why A before B.

Pavel


Next random bit :)
What do we do if some document class or module is missing on the remote side,
not providing environment, charstyle?

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Tommaso Cucinotta wrote:
 For example:
 -) I know, cases will grow fast...

If you suffer from good sleep, then start considering these:
- User adds external material (graphics,biblio, whatever). Now what?
- User runs various lfuns (and there are tons of doc-changing lfuns, start with 
search/replace eg).
- User is in the middle of citation dialog, another user deletes this 
citation/paragraph. Now what?
- We do lot of iterator/referencing computations 
(sections,figures,citations,cross-refs)
  so change at single point of document has potential to break things at any 
distance
  (paragraph based locking is not much of help).

Even with the simplistic ACK-based protocol (no write before peer's ACK) I 
proposed
as a first attempt, which will avoid _lot_ of the problems but migh be not good
enough for latency reasons, we are IMHO already in nightmare. 

Maybe JMarc could have a comment here: how hard would it be to reuse Undo 
(actually Redo)
stuff? This machinery must be already slightly independent on the current 
cursor position, no?
Instead of sending lfuns between peers, we would send redo actions which 
already contain
cursor info.

Pavel

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Nico Williams wrote:
 You can't do that. Assume chat servers/peers come and go.  You don't

I don't think we should assume such thing. This is online collaboration.
If you go offline, peer has either to wait or become independent and responsible
for merging problems not covered by LyX internal mechanism.

Pavel

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Nico Williams wrote:
 What's wrong with version control? 

- It would be very hard to avoid user assisted merging
  (online colab mechanism should be transparent to user)
- To do this stuff reliably you need much better integration
  with 3rd party VCS, most probaly including parts of its
  codebase and connect it to LyX internals. Fragile routines
  we currently have for rcs/cvs/svn/git are of no use.
  At the end it makes this project an order of magnitude harder task,
  not that it wouldn't be cute :)

Pavel

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 23:10, Marcelo Galvão Póvoa wrote:
 I think the best approach is not treating the LFUN as edits themselves
 but their effect on the document text instead.

Dispatching LFUNs has the advantage of not subverting the way LyX edits
docs, internally, and also re-use them. For example, you want to insert
a char, and that's exactly what's conveyed in LFUN_INSERT_SELF. Similarly
for delete actions. However, we simply need to fix and additionally send
more info about the position relative to which each action should be done
(i.e., doc or par ID, revision, and position within).

 Many of them doesn't
 touch the text, so it's useless to send to the other party.

When working the Advanced Find  Replace machinery, we had to distinguish
among LFUNs that would dispatch into the FR workarea, from ones that would
dispatch into the main document being edited workarea. I think that thing
is reusable for specifying which LFUNs should dispatch anyway locally, vs
which ones would go to the other side. It should be a further flag to be
added to the LFUN description in LyXAction.cpp.

 As for the
 others, the idea is to serialize each one into a string that represent
 their textual output. For example, it could be translated to LyX file
 syntax itself, couldn't it? The other party would deserialize this
 content filling the appropriate LyX data structures. I hope that the
 LyX functions for Save and Load could be reused for that matter.

You could, but I'm not sure about what advantage you get. LyX keeps in
memory a structured graph of C++ objects, not their serialized version.
If you send a serialized paragraph, then you have to de-serialize it
replacing the corresponding C++ object(s) on the other side, but a
paragraph may be very long. Instead, we might want to send just
the editing action, that normally should be smaller to be sent.

Also, when deleting a paragraph what do you send ? In the end, we need
anyway to send positions referring to affected parts of the document,
in a way that is as safe as possible considering others possibly being
editing other parts.

 I claim that the sorting algorithm I loosely described works for that
 purpose (maintaining consistency), assuming that all users generate
 edits based on the same revision.

But that's the critical point: users won't be able to generate edit msgs
based on the same revision, unless you synch all of them on a master doc.
That may be easy, as discussed with Nico, but it risks of resulting in a
bad experience (wait for a round-trip time before seeing any char on
screen ? hmmm)

Please, try to describe it in detail in your proposal, considering also
the issues discussed in this thread.

 As I see it, if others' cursors are close to mine, then when I start
 typing, LyX should delay a bit the action, so as to ensure I lock
 some part of text where others wouldn't be able to edit. Then, perhaps
 after a time-out I don't edit any more that part, it's released. The
 locked part might be highlighted some-way in the GUI, both for the
 user with the lock (~~green leftbar or similar), and for the one(s)
 without (~~red leftbar or similar).

 
 I agree with Nico here. A lock is not necessary: when someone starts
 editing a section, the others will see that and shouldn't interfere.

I'm absolutely all for users who will synch by themselves / other means,
in such cases. But, should a user try to edit over another user's cursor,
what'd you do ? I'm just saying LyX will automatically remind them that
they shouldn't be messing up with what the other guy is doing, in that
specific region of text. Otherwise they risk their edits to go lost.
Now, don't assume locking is bad. It's not a lock in the traditional
sense, just a highlighting of the risk.

Now, I can see two variations: I'm not allowed to edit such locked region,
which is what simplifies implementation. Or, when I try to edit, I get a
warning by LyX: look, I'm not sure I can make sense of concurrent edits.
Would you like to proceed ? If the user confirms, then apply some complex
transformational/whatever/git-like algorithm to make sense of the concurrent
edits possibly in a completely ordered and consistent fashion for all editors,
etc.

So, as I said: first lock to simplify implementation, later add the further
functionality. It may be yet another way to have intermediate checkpoints
in the project.

 knowing what was changed in each revision, it should be possible to
 re-send only the affected/changed parts...
 
 That's a possibility, but one would have to store a history of
 revisions in case it is needed by someone else.

Yes, and it should not be a problem to keep in memory a few edits, till
the protocol ensures that all editors have the same vision and allows
for discarding them.

And, about netsplits, it would really be great if LyX could cache locally the
changes to be sent to the other side(s) while off-line, then update when back
on-line. That would re-use the edits history/revisions 

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Liviu Andronic wrote:
 If an image-based approach is adopted, this would remove the need to
 either implement chat in LyX or implement a LyX buffer in a chat
 client. Both seem awkward and difficult to achieve.

How is this different from what was proposed already in this thread? Basically:
Out: Instant-preview-image-lyx pipe (or new lfun to call specific 
script)-pidgin addon
In: Pidgin addon-lyx pipe-lfun for paste

For the lyx part this is one weekend project not gsoc...
Pavel

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Marcelo Galv?o Póvoa wrote:
 On Mon, Apr 29, 2013 at 8:56 PM, Nico Williams n...@cryptonector.com wrote:
  BTW, this has all been solved before (clearly).  Research it and use
  whatever protocol pattern is most appropriate (or, if you can't
  because of patents, invent a new protocol).
 
  Some posts on this list pointed at some such prior work.
 
 I recently implemented a simple collaborative text editor focusing on
 maintaining consistency across multiple users edits. I have been
 following the discussion about the consistency related issues and
 there are indeed several possible approaches. I will try to briefly
 describe mine and you can comment about its (in)feasibility.

I can't comment whether your approach would work, but please think
how your approach work with several random bits:

- we don't have just linear structure of the document and sometimes
  distance of change can be tricky thing, e.g:
  - you delete title subsection 1.3.2, now all 1.3.4/5.. subsections must
be changed and numbering/reference from other parts of document must be 
correctly
recomputed. If there was label in 1.3.2, you have to find all crossrefs
on it and mark it broken.
  - you change the depth of subsection/paragraph - it affects the whole 
structure
around.
- innocent looking actions like cursor movement can change document strucutre
  - DEPM - you delete all characters in title of subsection 1.3.2 but
still let the empty line. Now another user _just_ move with the cursor
around this empty point. DEPM will immediately collapse the structure.
The same with double blanks.
- add/delete text is not enough. We modify. E.g. we make from equation 1.3
  unnumbered formula. Now all crossref links must be checked and other equation
  number recomputed. While I agree that we could disable some aspects of 
editation 
  disabling everything except add/remove text seems to make LyX slightly better
  notepad.

Pavel

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Wed, May 1, 2013 at 6:23 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
 You could, but I'm not sure about what advantage you get. LyX keeps in
 memory a structured graph of C++ objects, not their serialized version.
 If you send a serialized paragraph, then you have to de-serialize it
 replacing the corresponding C++ object(s) on the other side, but a
 paragraph may be very long. Instead, we might want to send just
 the editing action, that normally should be smaller to be sent.


What I'm proposing is basically keeping two different layers of
representation of the document at the same time. While redundant, it
would simplify several things due to code reuse and a simple protocol
for exchanging edits. The first layer is a textual representation (the
LyX format itself) and the other is the internal C++ objects
structure: these can be translated into one another.

The LFUNs are to be processed locally by existing code (modifying
internal objects) and when a user wants do dispatch his edits, he
should serialize (using export to file routines) the *modified*
objects and generate a *diff* of the string with the previous revision
(so small edits should be cheap). The user on the other side would get
this diff and apply to its textual representation, then deserialize
the affected snippets of text, replacing appropriate C++ objects.

Notice that the content which is being edited collaboratively is
actually the plain textual format, so a simple algorithm like the one
I proposed should be able to handle it with only insert string and
delete string operations. It should be also easy to maintain, since
the parts doing the dirty translation job are the import/export to
file routines.

 But that's the critical point: users won't be able to generate edit msgs
 based on the same revision, unless you synch all of them on a master doc.
 That may be easy, as discussed with Nico, but it risks of resulting in a
 bad experience (wait for a round-trip time before seeing any char on
 screen ? hmmm)


It doesn't require centralization, all users can agree on generating a
new revision in a synchronized fashion. Neither it requires blocked
wait, the user can keep generating edits to be sent at the next
revision step.

 I'm absolutely all for users who will synch by themselves / other means,
 in such cases. But, should a user try to edit over another user's cursor,
 what'd you do ? I'm just saying LyX will automatically remind them that
 they shouldn't be messing up with what the other guy is doing, in that
 specific region of text. Otherwise they risk their edits to go lost.
 Now, don't assume locking is bad. It's not a lock in the traditional
 sense, just a highlighting of the risk.

 Now, I can see two variations: I'm not allowed to edit such locked region,
 which is what simplifies implementation. Or, when I try to edit, I get a
 warning by LyX: look, I'm not sure I can make sense of concurrent edits.
 Would you like to proceed ? If the user confirms, then apply some complex
 transformational/whatever/git-like algorithm to make sense of the concurrent
 edits possibly in a completely ordered and consistent fashion for all editors,
 etc.


The warning could be generated as a courtesy, but in the approach I
described, the algorithm would be exactly the same and would be
consistent among all editors.

 That's a possibility, but one would have to store a history of
 revisions in case it is needed by someone else.

 Yes, and it should not be a problem to keep in memory a few edits, till
 the protocol ensures that all editors have the same vision and allows
 for discarding them.


I was thinking about a case in which a user disconnects for some time,
it would have to store a lot of earlier revisions.

Marcelo

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Wed, May 1, 2013 at 7:27 AM, Pavel Sanda sa...@lyx.org wrote:
 I can't comment whether your approach would work, but please think
 how your approach work with several random bits:

 - we don't have just linear structure of the document and sometimes
   distance of change can be tricky thing, e.g:
   - you delete title subsection 1.3.2, now all 1.3.4/5.. subsections must
 be changed and numbering/reference from other parts of document must be 
 correctly
 recomputed. If there was label in 1.3.2, you have to find all crossrefs
 on it and mark it broken.
   - you change the depth of subsection/paragraph - it affects the whole 
 structure
 around.
 - innocent looking actions like cursor movement can change document strucutre
   - DEPM - you delete all characters in title of subsection 1.3.2 but
 still let the empty line. Now another user _just_ move with the cursor
 around this empty point. DEPM will immediately collapse the structure.
 The same with double blanks.
 - add/delete text is not enough. We modify. E.g. we make from equation 1.3
   unnumbered formula. Now all crossref links must be checked and other 
 equation
   number recomputed. While I agree that we could disable some aspects of 
 editation
   disabling everything except add/remove text seems to make LyX slightly 
 better
   notepad.


Please check the description I just sent. These side effects of
editing would be handled normally at the internal representation
level, the data to be sent are the changes to the textual
representation (ie, modifications that would appear at the LyX file).

Marcelo

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Marcelo Galv?o Póvoa wrote:
 Please check the description I just sent. These side effects of
 editing would be handled normally at the internal representation
 level, the data to be sent are the changes to the textual
 representation (ie, modifications that would appear at the LyX file).

Just to check whether I understood your concept - you basically want to
synchronize the internal lyx structures between peers by using .lyx diffs as
transport layer, while hoping that full reconstruction from .lyx diff snippet
into lyx internal structure is possible, right?

Pavel

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Tommaso Cucinotta wrote:
> For example:
> -) I know, cases will grow fast...

If you suffer from good sleep, then start considering these:
- User adds external material (graphics,biblio, whatever). Now what?
- User runs various lfuns (and there are tons of doc-changing lfuns, start with 
search/replace eg).
- User is in the middle of citation dialog, another user deletes this 
citation/paragraph. Now what?
- We do lot of iterator/referencing computations 
(sections,figures,citations,cross-refs)
  so change at single point of document has potential to break things at any 
distance
  (paragraph based locking is not much of help).

Even with the simplistic ACK-based protocol (no write before peer's ACK) I 
proposed
as a first attempt, which will avoid _lot_ of the problems but migh be not good
enough for latency reasons, we are IMHO already in nightmare. 

Maybe JMarc could have a comment here: how hard would it be to reuse Undo 
(actually Redo)
stuff? This machinery must be already slightly independent on the current 
cursor position, no?
Instead of sending lfuns between peers, we would send "redo" actions which 
already contain
cursor info.

Pavel

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Nico Williams wrote:
> You can't do that. Assume chat servers/peers come and go.  You don't

I don't think we should assume such thing. This is online collaboration.
If you go offline, peer has either to wait or become independent and responsible
for merging problems not covered by LyX internal mechanism.

Pavel

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Nico Williams wrote:
> What's wrong with version control? 

- It would be very hard to avoid user assisted merging
  (online colab mechanism should be transparent to user)
- To do this stuff reliably you need much better integration
  with 3rd party VCS, most probaly including parts of its
  codebase and connect it to LyX internals. Fragile routines
  we currently have for rcs/cvs/svn/git are of no use.
  At the end it makes this project an order of magnitude harder task,
  not that it wouldn't be cute :)

Pavel

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 23:10, Marcelo Galvão Póvoa wrote:
> I think the best approach is not treating the LFUN as edits themselves
> but their effect on the document text instead.

Dispatching LFUNs has the advantage of not subverting the way LyX edits
docs, internally, and also re-use them. For example, you want to insert
a char, and that's exactly what's conveyed in LFUN_INSERT_SELF. Similarly
for delete actions. However, we simply need to fix and additionally send
more info about the position relative to which each action should be done
(i.e., doc or par ID, revision, and position within).

> Many of them doesn't
> touch the text, so it's useless to send to the other party.

When working the Advanced Find & Replace machinery, we had to distinguish
among LFUNs that would dispatch into the F workarea, from ones that would
dispatch into the main document being edited workarea. I think that thing
is reusable for specifying which LFUNs should dispatch anyway locally, vs
which ones would go to the other side. It should be a further flag to be
added to the LFUN description in LyXAction.cpp.

> As for the
> others, the idea is to serialize each one into a string that represent
> their textual output. For example, it could be translated to LyX file
> syntax itself, couldn't it? The other party would deserialize this
> content filling the appropriate LyX data structures. I hope that the
> LyX functions for Save and Load could be reused for that matter.

You could, but I'm not sure about what advantage you get. LyX keeps in
memory a structured graph of C++ objects, not their serialized version.
If you send a serialized paragraph, then you have to de-serialize it
replacing the corresponding C++ object(s) on the other side, but a
paragraph may be very long. Instead, we might want to send just
the editing action, that normally should be smaller to be sent.

Also, when deleting a paragraph what do you send ? In the end, we need
anyway to send positions referring to affected parts of the document,
in a way that is as safe as possible considering others possibly being
editing other parts.

> I claim that the sorting algorithm I loosely described works for that
> purpose (maintaining consistency), assuming that all users generate
> edits based on the same revision.

But that's the critical point: users won't be able to generate edit msgs
based on the same revision, unless you synch all of them on a master doc.
That may be easy, as discussed with Nico, but it risks of resulting in a
bad experience (wait for a round-trip time before seeing any char on
screen ? hmmm)

Please, try to describe it in detail in your proposal, considering also
the issues discussed in this thread.

>> As I see it, if others' cursors are close to mine, then when I start
>> typing, LyX should delay a bit the action, so as to ensure I "lock"
>> some part of text where others wouldn't be able to edit. Then, perhaps
>> after a time-out I don't edit any more that part, it's released. The
>> locked part might be highlighted some-way in the GUI, both for the
>> user with the lock (~~green leftbar or similar), and for the one(s)
>> without (~~red leftbar or similar).
>>
> 
> I agree with Nico here. A lock is not necessary: when someone starts
> editing a section, the others will see that and shouldn't interfere.

I'm absolutely all for users who will synch by themselves / other means,
in such cases. But, should a user try to edit over another user's cursor,
what'd you do ? I'm just saying LyX will automatically remind them that
they shouldn't be messing up with what the other guy is doing, in that
specific region of text. Otherwise they risk their edits to go lost.
Now, don't assume locking is bad. It's not a lock in the traditional
sense, just a highlighting of the risk.

Now, I can see two variations: I'm not allowed to edit such locked region,
which is what simplifies implementation. Or, when I try to edit, I get a
warning by LyX: look, I'm not sure I can make sense of concurrent edits.
Would you like to proceed ? If the user confirms, then apply some complex
transformational/whatever/git-like algorithm to make sense of the concurrent
edits possibly in a completely ordered and consistent fashion for all editors,
etc.

So, as I said: first lock to simplify implementation, later add the further
functionality. It may be yet another way to have intermediate checkpoints
in the project.

>> knowing what was changed in each revision, it should be possible to
>> re-send only the affected/changed parts...
> 
> That's a possibility, but one would have to store a history of
> revisions in case it is needed by someone else.

Yes, and it should not be a problem to keep in memory a few edits, till
the protocol ensures that all editors have the same vision and allows
for discarding them.

And, about netsplits, it would really be great if LyX could cache locally the
changes to be sent to the other side(s) while off-line, then update when back
on-line. That would 

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Liviu Andronic wrote:
> If an image-based approach is adopted, this would remove the need to
> either implement chat in LyX or implement a LyX buffer in a chat
> client. Both seem awkward and difficult to achieve.

How is this different from what was proposed already in this thread? Basically:
Out: Instant-preview->image->lyx pipe (or new lfun to call specific 
script)->pidgin addon
In: Pidgin addon->lyx pipe->lfun for paste

For the lyx part this is one weekend project not gsoc...
Pavel

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Marcelo Galv?o Póvoa wrote:
> On Mon, Apr 29, 2013 at 8:56 PM, Nico Williams  wrote:
> > BTW, this has all been solved before (clearly).  Research it and use
> > whatever protocol pattern is most appropriate (or, if you can't
> > because of patents, invent a new protocol).
> >
> > Some posts on this list pointed at some such prior work.
> 
> I recently implemented a simple collaborative text editor focusing on
> maintaining consistency across multiple users edits. I have been
> following the discussion about the consistency related issues and
> there are indeed several possible approaches. I will try to briefly
> describe mine and you can comment about its (in)feasibility.

I can't comment whether your approach would work, but please think
how your approach work with several random bits:

- we don't have just linear structure of the document and sometimes
  distance of change can be tricky thing, e.g:
  - you delete title subsection 1.3.2, now all 1.3.4/5.. subsections must
be changed and numbering/reference from other parts of document must be 
correctly
recomputed. If there was label in 1.3.2, you have to find all crossrefs
on it and mark it broken.
  - you change the depth of subsection/paragraph - it affects the whole 
structure
around.
- innocent looking actions like cursor movement can change document strucutre
  - DEPM -> you delete all characters in title of subsection 1.3.2 but
still let the empty line. Now another user _just_ move with the cursor
around this empty point. DEPM will immediately collapse the structure.
The same with double blanks.
- add/delete text is not enough. We modify. E.g. we make from equation 1.3
  unnumbered formula. Now all crossref links must be checked and other equation
  number recomputed. While I agree that we could disable some aspects of 
editation 
  disabling everything except add/remove text seems to make LyX slightly better
  notepad.

Pavel

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Wed, May 1, 2013 at 6:23 AM, Tommaso Cucinotta  wrote:
> You could, but I'm not sure about what advantage you get. LyX keeps in
> memory a structured graph of C++ objects, not their serialized version.
> If you send a serialized paragraph, then you have to de-serialize it
> replacing the corresponding C++ object(s) on the other side, but a
> paragraph may be very long. Instead, we might want to send just
> the editing action, that normally should be smaller to be sent.
>

What I'm proposing is basically keeping two different layers of
representation of the document at the same time. While redundant, it
would simplify several things due to code reuse and a simple protocol
for exchanging edits. The first layer is a textual representation (the
LyX format itself) and the other is the internal C++ objects
structure: these can be translated into one another.

The LFUNs are to be processed locally by existing code (modifying
internal objects) and when a user wants do dispatch his edits, he
should serialize (using export to file routines) the *modified*
objects and generate a *diff* of the string with the previous revision
(so small edits should be cheap). The user on the other side would get
this diff and apply to its textual representation, then deserialize
the affected snippets of text, replacing appropriate C++ objects.

Notice that the content which is being edited collaboratively is
actually the plain textual format, so a simple algorithm like the one
I proposed should be able to handle it with only "insert string" and
"delete string" operations. It should be also easy to maintain, since
the parts doing the dirty translation job are the import/export to
file routines.

> But that's the critical point: users won't be able to generate edit msgs
> based on the same revision, unless you synch all of them on a master doc.
> That may be easy, as discussed with Nico, but it risks of resulting in a
> bad experience (wait for a round-trip time before seeing any char on
> screen ? hmmm)
>

It doesn't require centralization, all users can agree on generating a
new revision in a synchronized fashion. Neither it requires blocked
wait, the user can keep generating edits to be sent at the next
revision step.

> I'm absolutely all for users who will synch by themselves / other means,
> in such cases. But, should a user try to edit over another user's cursor,
> what'd you do ? I'm just saying LyX will automatically remind them that
> they shouldn't be messing up with what the other guy is doing, in that
> specific region of text. Otherwise they risk their edits to go lost.
> Now, don't assume locking is bad. It's not a lock in the traditional
> sense, just a highlighting of the risk.
>
> Now, I can see two variations: I'm not allowed to edit such locked region,
> which is what simplifies implementation. Or, when I try to edit, I get a
> warning by LyX: look, I'm not sure I can make sense of concurrent edits.
> Would you like to proceed ? If the user confirms, then apply some complex
> transformational/whatever/git-like algorithm to make sense of the concurrent
> edits possibly in a completely ordered and consistent fashion for all editors,
> etc.
>

The warning could be generated as a courtesy, but in the approach I
described, the algorithm would be exactly the same and would be
consistent among all editors.

>> That's a possibility, but one would have to store a history of
>> revisions in case it is needed by someone else.
>
> Yes, and it should not be a problem to keep in memory a few edits, till
> the protocol ensures that all editors have the same vision and allows
> for discarding them.
>

I was thinking about a case in which a user disconnects for some time,
it would have to store a lot of earlier revisions.

Marcelo

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Wed, May 1, 2013 at 7:27 AM, Pavel Sanda  wrote:
> I can't comment whether your approach would work, but please think
> how your approach work with several random bits:
>
> - we don't have just linear structure of the document and sometimes
>   distance of change can be tricky thing, e.g:
>   - you delete title subsection 1.3.2, now all 1.3.4/5.. subsections must
> be changed and numbering/reference from other parts of document must be 
> correctly
> recomputed. If there was label in 1.3.2, you have to find all crossrefs
> on it and mark it broken.
>   - you change the depth of subsection/paragraph - it affects the whole 
> structure
> around.
> - innocent looking actions like cursor movement can change document strucutre
>   - DEPM -> you delete all characters in title of subsection 1.3.2 but
> still let the empty line. Now another user _just_ move with the cursor
> around this empty point. DEPM will immediately collapse the structure.
> The same with double blanks.
> - add/delete text is not enough. We modify. E.g. we make from equation 1.3
>   unnumbered formula. Now all crossref links must be checked and other 
> equation
>   number recomputed. While I agree that we could disable some aspects of 
> editation
>   disabling everything except add/remove text seems to make LyX slightly 
> better
>   notepad.
>

Please check the description I just sent. These side effects of
editing would be handled normally at the internal representation
level, the data to be sent are the changes to the textual
representation (ie, modifications that would appear at the LyX file).

Marcelo

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Marcelo Galv?o Póvoa wrote:
> Please check the description I just sent. These side effects of
> editing would be handled normally at the internal representation
> level, the data to be sent are the changes to the textual
> representation (ie, modifications that would appear at the LyX file).

Just to check whether I understood your concept - you basically want to
synchronize the internal lyx structures between peers by using .lyx diffs as
transport layer, while hoping that full reconstruction from .lyx diff snippet
into lyx internal structure is possible, right?

Pavel

Re: GSoC 2013: Interactive LyX

[Liviu Andronic]

On Tue, Apr 30, 2013 at 12:09 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
 OTOH interactive LyX seems to be really worth and requested feature while the
 chat looks more like a toy with the aroma of the word bloat around (sorry 
 for
 the punch :)

 I'm not sure here: AFAICS, I'd see myself more needing the chat, for 
 discussing
 ideas with colleagues *live*. The interactive editing is something that 
 crosses
 with version control. I mean, I've been writing papers over CVS, SVN and GIT,
 and I couldn't really see the problem with the classical way of handling the
 interactions and conflicts in these systems. Actually, being capable of 
 handling
 the editing and commits/conflicts resolution *off-line* is valuable as well.

I must admit that I share Pavel's sentiment: I'm not sure how much the
community needs/requires a chatting function in LyX. But I was
thinking of possibly a cheap workaround: Why not communicate with
images?

If http://www.lyx.org/trac/ticket/7839 gets included in base LyX, then
it should be much easier to create an LFUN that allows to convert a
document to PDF, pass it through pdfcrop (or similar), transform it
into a bitmap image and copy it to the clipboard. A bit in the style
of Instant Preview. Then the user could insert the resulting image in
any chatting application that supports images (I would suspect Pidgin
does). As a perk we could check if it would be possible to embed the
LyX code that produced the image into the image metadata, and teach
LyX to recognize such metadata: If so, then the receiving user could
insert the image in LyX and LyX would automatically re-integrate the
code into the document.

If an image-based approach is adopted, this would remove the need to
either implement chat in LyX or implement a LyX buffer in a chat
client. Both seem awkward and difficult to achieve.

Anyways, a wild idea. Regards,
Liviu

Re: GSoC 2013: Interactive LyX

[Cyrille Artho]

I must admit that I share Pavel's sentiment: I'm not sure how much the
community needs/requires a chatting function in LyX. But I was
thinking of possibly a cheap workaround: Why not communicate with
images?


Good point. In the age of Skype etc., and with many existing good chat clients,
why implement a new one poorly? Note that collaborative editing is 
different from that, and of course a small chat interface there may be 
useful, but the core would still be collaborative editing.

--
Regards,
Cyrille Artho - http://artho.com/
British education is probably the best in the world, if you can survive
it. If you can't there is nothing left for you but the diplomatic corps.
-- Peter Ustinov

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 08:49, Liviu Andronic wrote:
 But I was
 thinking of possibly a cheap workaround: Why not communicate with
 images?

hmmm.. that sounds like a hack.., would usability be the same ? or the
user would have to switch back and forth among the chat client and lyx
to do this, for handling connection set-up as well as copy'n'paste images
back and forth ?

 Anyways, a wild idea. Regards,

yep..., seems wild :-)!

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 00:23, Nico Williams wrote:
 Well...  If a paragraph is deleted then the pointer might get assigned
 in a subsequent allocation and... you end up with an aliasing problem.

I was thinking of detecting this problem when you delete a par, going through
the cursors/pointers potentially affected, but as you say the criticality is
not local to the LyX instance where the 2 cursors are, that's easy. The problem
is how to synch this forced cursor movement (e.g., going out of the deleted
region, or the incr in pos etc...) with the remote instance in which that
cursor is still editing and get the same outcome in both.

 you don't want to implement a
 distributed locking protocol (for the same reason).

some locking may be the easy way to avoid some of the biggest problems in the 
first instance.
I mean, even with git, there are situations of concurrent edit where the tool 
simply cannot
merge the edits. It has to be done by humans. By locking, you avoid that 
situation to happen.

  Nor do you want
 to worry about split-brains (netsplits).

pls, explain ?

 Version everything and assign version numbers; keep history.
 Alternatively use hash-of-paragraph-contents as version numbers; keep
 history.

sounds a bit like replicating the git functionality inside lyx, is it 
really needed ?

Let me see: each one keeps a copy of the last edits by everybody, at some point 
the protocol
sorts out the agreed-upon order of the actions, and each client ensures that 
all actions
are played back in the same order (e.g., undo-es the last needed # of actions, 
and replays
them back in the agreed-upon order). Not sure what the GUI (and user-face) 
looks like while
this is happening ... :-), but it might be needed.

T.

Re: GSoC 2013: Interactive LyX

[Liviu Andronic]

On Tue, Apr 30, 2013 at 10:16 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 30/04/13 08:49, Liviu Andronic wrote:
 But I was
 thinking of possibly a cheap workaround: Why not communicate with
 images?

 hmmm.. that sounds like a hack.., would usability be the same ? or the
 user would have to switch back and forth among the chat client and lyx
 to do this, for handling connection set-up as well as copy'n'paste images
 back and forth ?

Well, it could nicely take the form of a Pidgin plugin:
- The plugin would be communicating to an existing LyX session (set up
a link, etc., to associate a LyX instance/buffer with a chat
conversation window)
- The user would create some material in the LyX buffer (text, image,
formula, what have you)
- By activating an LFUN (button, shortcut) the document would get
compiled, cropped, converted to image (if PDF is not supported in the
chat thingy), Instant Preview-style, and sent to the Pidgin
conversation and directly to the receiving user
- If there is a way to embed LyX code into the PDF/image metadata, the
receiving Pidgin client would allow to press a button and integrate
the received image (more precisely, the embedded code) into an
associated LyX buffer.

I'm no expert, but the basic idea would be to associate two LyX
instances with two chat clients, use PDF/images for rendering complex
LyX content in the chat clients, and additionally/optionally transfer
the code (via a file, as image metadata, etc.) from one LyX instance
via the chat clients to the 2nd LyX instance. Maybe this needs to be
thought through, but all this sounds to me cheap, useful, secure and
achievable during a GSoC project.


 Anyways, a wild idea. Regards,

 yep..., seems wild :-)!

I've already got two replies, so maybe there is something to it. :)

Liviu


 T.




-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Tue, Apr 30, 2013 at 2:49 AM, Liviu Andronic landronim...@gmail.com wrote:
 I must admit that I share Pavel's sentiment: I'm not sure how much the
 community needs/requires a chatting function in LyX. But I was
 thinking of possibly a cheap workaround: Why not communicate with
 images?

LyX doesn't.  Getting through firewalls, networking easily, recommends
it.  It's not about IM (though that would help collaborating authors);
it's about communications using something better than unicast IP
addressing.

Note that LyX could talk to an external program that does all the IM
work, via pipes/socketpairs/whatever IPC.

Nico
--

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Tue, Apr 30, 2013 at 3:26 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 30/04/13 00:23, Nico Williams wrote:
 Well...  If a paragraph is deleted then the pointer might get assigned
 in a subsequent allocation and... you end up with an aliasing problem.

 I was thinking of detecting this problem when you delete a par, going through
 the cursors/pointers potentially affected, but as you say the criticality is
 not local to the LyX instance where the 2 cursors are, that's easy. The 
 problem
 is how to synch this forced cursor movement (e.g., going out of the deleted
 region, or the incr in pos etc...) with the remote instance in which that
 cursor is still editing and get the same outcome in both.

Right.

 you don't want to implement a
 distributed locking protocol (for the same reason).

 some locking may be the easy way to avoid some of the biggest problems in the 
 first instance.
 I mean, even with git, there are situations of concurrent edit where the tool 
 simply cannot
 merge the edits. It has to be done by humans. By locking, you avoid that 
 situation to happen.

git. does. not. lock.  (except, in the case of a remote, it locks
briefly around applying commits sent by a client, but what git does
while it holds this lock does not include waiting for I/O from/to any
client.)

Manual merges may be inescapable.  But sometimes you can just avoid it
using brute force.  E.g., one user selects and deletes a paragraph (or
more) while another was typing in that paragraph - just delete the
paragraphs and make the second user have to click somewhere to get a
cursor back.  AND, a) let the two users bicker over IM :) b) let the
users undo the winning change (the deletion).

I haven't thought through all the possible conflicts scenarios, but I
think that as long as the clients eventually exchange enough messages
you can make them converge.

  Nor do you want
 to worry about split-brains (netsplits).

 pls, explain ?

Part of the XMPP/whatever fabric gets disconnected from the rest.  Now
you have two LyX instances collaborating but unable to reach each
other.  What do you do now?  If each user is allowed to keep making
changes that are not acknowledged by the other then conflicts will
pile up, and resolving them will be a mess.  But not letting the users
make progress makes for a poor user experience.

Note that once more, a three-way diff/merge tool for LyX here would be
extremely handy: if two (or more) instances of LyX diverge long enough
because of a split then one user could do a merge and cleanup
conflicts, then push the results to the others.

 Version everything and assign version numbers; keep history.
 Alternatively use hash-of-paragraph-contents as version numbers; keep
 history.

 sounds a bit like replicating the git functionality inside lyx, is it 
 really needed ?

Flatly?  Yes.  git doesn't know the semantics of the data it deals
with.  And git's diff/merge doesn't either.  And I suspect that git
diff/merge is not appropriate for merging LyX documents.

 Let me see: each one keeps a copy of the last edits by everybody, at some 
 point the protocol
 sorts out the agreed-upon order of the actions, and each client ensures that 
 all actions
 are played back in the same order (e.g., undo-es the last needed # of 
 actions, and replays
 them back in the agreed-upon order). Not sure what the GUI (and user-face) 
 looks like while
 this is happening ... :-), but it might be needed.

Yes, this.

BUT, you should research what Google and others with online
collaboration do.  I suspect they have it easier: there's only one
instance of the editor and the GUIs (BUIs) are clients of it, in which
case there's no merging to worry about, no netsplits, nada.

For this you could have one instance of LyX act as a master and the
others do everything via the master, in which case the users of the
non-master instance will feel latency (but no worse than with any
other client/server collaboration editors).  This will probably be a
lot easier.

Nico
--

Re: GSoC 2013: Interactive LyX

[Albus X]

Hello. In my opinion, cooperative editing the same paragraph does not
make sense. I will be annoyed if the paragraph I am editing change
from time to time making the structure and meaning and everything a
mess. I suggest that we could simply lock that paragraph while others
can commenting on it, leaving everything to the editor. And the inline
comments act also as a todo list on the editor side, the editor can
tick it when the advice is taken, or reply to explain why not. Every
comment not ticked should be left for the file owner to make a
decision.

On Tue, Apr 30, 2013 at 5:51 PM, Nico Williams n...@cryptonector.com wrote:
 On Tue, Apr 30, 2013 at 3:26 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 30/04/13 00:23, Nico Williams wrote:
 Well...  If a paragraph is deleted then the pointer might get assigned
 in a subsequent allocation and... you end up with an aliasing problem.

 I was thinking of detecting this problem when you delete a par, going through
 the cursors/pointers potentially affected, but as you say the criticality is
 not local to the LyX instance where the 2 cursors are, that's easy. The 
 problem
 is how to synch this forced cursor movement (e.g., going out of the deleted
 region, or the incr in pos etc...) with the remote instance in which that
 cursor is still editing and get the same outcome in both.

 Right.

 you don't want to implement a
 distributed locking protocol (for the same reason).

 some locking may be the easy way to avoid some of the biggest problems in 
 the first instance.
 I mean, even with git, there are situations of concurrent edit where the 
 tool simply cannot
 merge the edits. It has to be done by humans. By locking, you avoid that 
 situation to happen.

 git. does. not. lock.  (except, in the case of a remote, it locks
 briefly around applying commits sent by a client, but what git does
 while it holds this lock does not include waiting for I/O from/to any
 client.)

 Manual merges may be inescapable.  But sometimes you can just avoid it
 using brute force.  E.g., one user selects and deletes a paragraph (or
 more) while another was typing in that paragraph - just delete the
 paragraphs and make the second user have to click somewhere to get a
 cursor back.  AND, a) let the two users bicker over IM :) b) let the
 users undo the winning change (the deletion).

 I haven't thought through all the possible conflicts scenarios, but I
 think that as long as the clients eventually exchange enough messages
 you can make them converge.

  Nor do you want
 to worry about split-brains (netsplits).

 pls, explain ?

 Part of the XMPP/whatever fabric gets disconnected from the rest.  Now
 you have two LyX instances collaborating but unable to reach each
 other.  What do you do now?  If each user is allowed to keep making
 changes that are not acknowledged by the other then conflicts will
 pile up, and resolving them will be a mess.  But not letting the users
 make progress makes for a poor user experience.

 Note that once more, a three-way diff/merge tool for LyX here would be
 extremely handy: if two (or more) instances of LyX diverge long enough
 because of a split then one user could do a merge and cleanup
 conflicts, then push the results to the others.

 Version everything and assign version numbers; keep history.
 Alternatively use hash-of-paragraph-contents as version numbers; keep
 history.

 sounds a bit like replicating the git functionality inside lyx, is it 
 really needed ?

 Flatly?  Yes.  git doesn't know the semantics of the data it deals
 with.  And git's diff/merge doesn't either.  And I suspect that git
 diff/merge is not appropriate for merging LyX documents.

 Let me see: each one keeps a copy of the last edits by everybody, at some 
 point the protocol
 sorts out the agreed-upon order of the actions, and each client ensures that 
 all actions
 are played back in the same order (e.g., undo-es the last needed # of 
 actions, and replays
 them back in the agreed-upon order). Not sure what the GUI (and user-face) 
 looks like while
 this is happening ... :-), but it might be needed.

 Yes, this.

 BUT, you should research what Google and others with online
 collaboration do.  I suspect they have it easier: there's only one
 instance of the editor and the GUIs (BUIs) are clients of it, in which
 case there's no merging to worry about, no netsplits, nada.

 For this you could have one instance of LyX act as a master and the
 others do everything via the master, in which case the users of the
 non-master instance will feel latency (but no worse than with any
 other client/server collaboration editors).  This will probably be a
 lot easier.

 Nico
 --

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Mon, Apr 29, 2013 at 8:56 PM, Nico Williams n...@cryptonector.com wrote:
 BTW, this has all been solved before (clearly).  Research it and use
 whatever protocol pattern is most appropriate (or, if you can't
 because of patents, invent a new protocol).

 Some posts on this list pointed at some such prior work.

I recently implemented a simple collaborative text editor focusing on
maintaining consistency across multiple users edits. I have been
following the discussion about the consistency related issues and
there are indeed several possible approaches. I will try to briefly
describe mine and you can comment about its (in)feasibility.

The main difference is that I was using a coordinating server, but I
believe centralized steps can be turned into distributed ones. The
edits are only of types insert text or delete text, represented as
(global-offset, type, data), where global-offset is the offset from
the beginning of the document (I intentionally avoided dealing with
paragraphs operations explicitly) and data is the inserted string
(including line breaks) or the number of characters to delete from
that position, depending on the edit type.

A document revision is a document state (identified by an integer)
which all users know and agree upon. A user state is the latest known
revision and a set of new own edits, in which all offsets are
calculated relative to this last revision. Periodically, the server
asks for creating a new revision in which all users share their own
edits, which can be merged for efficiency (e.g., put many consecutive
insertions/deletions into a single edit). To generate a new revision
from a set of edits, you have to incrementally apply each of them (to
the last revision) sorted by increasing offsets, keeping track of how
many characters you have added/removed so far to be able to pinpoint
the correct location to apply.

The main advantages of this approach are simplicity and avoid dealing
with locking, conflicts, etc. As someone mentioned, when two users are
editing too close to each other, there is no correct result for this.
As a drawback, clients need to keep track of the latest document
revision: if one misses a revision (the user leaves but the document
keeps being edited by others), he should ask someone for the whole
document.

Regards,
Marcelo

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 10:51, Nico Williams wrote:
 Part of the XMPP/whatever fabric gets disconnected from the rest.  Now
 you have two LyX instances collaborating but unable to reach each
 other.  What do you do now?  If each user is allowed to keep making
 changes that are not acknowledged by the other then conflicts will
 pile up, and resolving them will be a mess.  But not letting the users
 make progress makes for a poor user experience.

Guess everybody would love to be able to keep editing, and saving locally
their changes, so that next time (the day after) the other user comes back
on-line, things can synch-up again. But, that sounds a lot like version
control (again), rather than interactive editing.

If it has to be interactive editing, then perhaps stopping the user is the
right thing to do ?

Or, as you said, we actually need a lyx-aware version control system that
is capable of merging edits, and also 

 Note that once more, a three-way diff/merge tool for LyX here would be
 extremely handy: if two (or more) instances of LyX diverge long enough
 because of a split then one user could do a merge and cleanup
 conflicts, then push the results to the others.

... and also being capable of triggering a compare panel (Compare Document
might be re-used here ?) where the user sorts out conflicts.

 For this you could have one instance of LyX act as a master and the
 others do everything via the master, in which case the users of the
 non-master instance will feel latency (but no worse than with any
 other client/server collaboration editors).  This will probably be a
 lot easier.

You mean, edits actually happen only on the master, and each client/slave
only sees updates as reflected and serialized by the master ? yes, a lot
easier, but perhaps very slow/unusable over the Internet.

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 21:12, Marcelo Galvão Póvoa wrote:
 there are indeed several possible approaches. I will try to briefly
 describe mine and you can comment about its (in)feasibility.

As you say, your case was far easier, and it seems to correspond to the
simple scenario of editing text in a text-only paragraph.
Criticalities already discussed on the list: keep position as an offset,
it's basically what LyX does, but in a structured form. A Cursor is a
stack of CursorSlice, where each slice is basically a triplet

  pos, pit, idx

where pos indicates the character position in the text, pit (ParagraphIT)
indicates the paragraph number in the multi-paragraph text, idx indicates
what cell of a multi-cell table we're in. Then, we have a stack of these,
because in a given pos we might have, instead of a normal character, a
kind of placeholder indicating there's an inset there. So, we go to the
inset, which in turn is another kind-of LyX text, with potentially its
own multi-paragraph text etc

So, another user edits creating further pars or deleting pars, and we
need to pay attention to cursor positions after them.

 edits are only of types insert text or delete text, represented as
 (global-offset, type, data),

pls, have a look at LyXAction.cpp to get a feeling of the possible edit
actions that users might be willing to do (I'm not pretending that all
of them should work in the interactive editing mode -- perhaps we just
allow a subset of them to be used in that mode; ideally, we'd like all
of them to keep working).

Now, the hack I did, was rude: keep the serialized LFUN (in form of
text), send to the other side, reconstruct the LFUN, dispatch it
locally. INCLUDING CURSOR MOVEMENTS, which are relative (go up, go
right one char, etc...). That was causing easy de-synch between the
two sides, about what position the cursor is, when dispatching an
editing LFUN. So, there should be a way to exchange and keep in synch
the cursor position independently of the multiple edits being merged
within the doc.

That's why sb. proposed to use par hashes to identify the par, or global
unique identifiers, etc We all know how a version control system
does that, by the +/- 3 lines around the edit..., and we know the
limitation of such an approach. What can we do in such case ?

 A document revision is a document state (identified by an integer)

Good. Doc revision may be helpful. As highlighted by Nico, if we know
the revision against which an editing LFUN dispatch was meant, we might
know what position to affect, but still in case of replay of other users'
concurrent editing LFUNs, the key point is how to translate/transform
the subsequent actions..

 The main advantages of this approach are simplicity and avoid dealing
 with locking, conflicts, etc.

would it be applicable to the nested/structured LyX text, as described
above ? or, how to extend it properly in such case ?

 As someone mentioned, when two users are
 editing too close to each other, there is no correct result for this.

As I see it, if others' cursors are close to mine, then when I start
typing, LyX should delay a bit the action, so as to ensure I lock
some part of text where others wouldn't be able to edit. Then, perhaps
after a time-out I don't edit any more that part, it's released. The
locked part might be highlighted some-way in the GUI, both for the
user with the lock (~~green leftbar or similar), and for the one(s)
without (~~red leftbar or similar).

Just thinking aloud, it might be extremely handy to have a chat pane
for being able to discuss about the doc while editing, w/out typing
the stuff straight into the doc :-)!

In the end, I keep seeing lots of relations within the two projects,
with possibly the chat being a part of the overall collaboration
features.

 As a drawback, clients need to keep track of the latest document
 revision: if one misses a revision (the user leaves but the document
 keeps being edited by others), he should ask someone for the whole
 document.

knowing what was changed in each revision, it should be possible to
re-send only the affected/changed parts...

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Tue, Apr 30, 2013 at 3:41 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 30/04/13 10:51, Nico Williams wrote:
 Part of the XMPP/whatever fabric gets disconnected from the rest.  Now
 you have two LyX instances collaborating but unable to reach each
 other.  What do you do now?  If each user is allowed to keep making
 changes that are not acknowledged by the other then conflicts will
 pile up, and resolving them will be a mess.  But not letting the users
 make progress makes for a poor user experience.

 Guess everybody would love to be able to keep editing, and saving locally
 their changes, so that next time (the day after) the other user comes back
 on-line, things can synch-up again. But, that sounds a lot like version
 control (again), rather than interactive editing.

What's wrong with version control?  In fact, re-use the existing
change tracking UI but add colors or labels to identify authors.  On
conflict just pick a winner (deterministically) and the loser will
notice (or better: be told).

Locking will. not. work. well.   Maybe I'm being too categorical
but... all my experience says locking won't work.

 If it has to be interactive editing, then perhaps stopping the user is the
 right thing to do ?

I've used a few interactive online collaborative editors before.  Not
one locked a user out of a paragraph/section/whatever.  I can't
imagine being pleased with a UI that required the user be aware of
locks, even if only in the case of being locked out.

OTOH, consider the online editors I've seen (like, e.g., Google docs).
 You generally get to see other users' cursors and typing almost in
real-time if your window has the relevant document sections in view.
The very appearance of another user's cursor in a paragraph that
you're editing should be enough for you to pop up an IM to the other
saying hands-off man, I'm doing some major surgery on the paragraph.
 This only fails in the case of netsplits.  Now, if one editor is
considered a master then the peers that are cut-off from it will stop
editing; while if all editors are equal and the whole process is truly
distributed and peer-to-peer, then you absolutely need either
deterministic conflict resolution (in some cases destructive) or
manual conflict merges.

I think the latter is a much better user experience.  Users know how
to talk to each other and arbitrate who works on what.

 Or, as you said, we actually need a lyx-aware version control system that
 is capable of merging edits, and also 

But you might be able to avoid having to bite that bullet.  But if you
do bite this bullet, the rest of us will be oh-so-happy.

 Note that once more, a three-way diff/merge tool for LyX here would be
 extremely handy: if two (or more) instances of LyX diverge long enough
 because of a split then one user could do a merge and cleanup
 conflicts, then push the results to the others.

 ... and also being capable of triggering a compare panel (Compare Document
 might be re-used here ?) where the user sorts out conflicts.

Maybe.  But see above.

 For this you could have one instance of LyX act as a master and the
 others do everything via the master, in which case the users of the
 non-master instance will feel latency (but no worse than with any
 other client/server collaboration editors).  This will probably be a
 lot easier.

 You mean, edits actually happen only on the master, and each client/slave
 only sees updates as reflected and serialized by the master ? yes, a lot
 easier, but perhaps very slow/unusable over the Internet.

Yes.  Well, no, it works for Google and others.  Over an XMPP fabric
it should work fine too.  On netsplit the non-master peers cut-off
from the master can stop allowing local edits, or fallback on conflict
resolution later when the netsplit is resolved.

Offline collaboration (e.g., online when I'm not on an airplane,
offline when I am) would be wonderful, and this is where true 3-way
diff/merge with LyX semantics would be awesome.

Nico
--

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Tue, Apr 30, 2013 at 6:06 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 30/04/13 21:12, Marcelo Galvăo Póvoa wrote:
 there are indeed several possible approaches. I will try to briefly
 describe mine and you can comment about its (in)feasibility.

 As you say, your case was far easier, and it seems to correspond to the
 simple scenario of editing text in a text-only paragraph.
 Criticalities already discussed on the list: keep position as an offset,
 it's basically what LyX does, but in a structured form. A Cursor is a
 stack of CursorSlice, where each slice is basically a triplet

   pos, pit, idx

 where pos indicates the character position in the text, pit (ParagraphIT)
 indicates the paragraph number in the multi-paragraph text, idx indicates
 what cell of a multi-cell table we're in. Then, we have a stack of these,
 because in a given pos we might have, instead of a normal character, a
 kind of placeholder indicating there's an inset there. So, we go to the
 inset, which in turn is another kind-of LyX text, with potentially its
 own multi-paragraph text etc

 So, another user edits creating further pars or deleting pars, and we
 need to pay attention to cursor positions after them.

 edits are only of types insert text or delete text, represented as
 (global-offset, type, data),

 pls, have a look at LyXAction.cpp to get a feeling of the possible edit
 actions that users might be willing to do (I'm not pretending that all
 of them should work in the interactive editing mode -- perhaps we just
 allow a subset of them to be used in that mode; ideally, we'd like all
 of them to keep working).


I think the best approach is not treating the LFUN as edits themselves
but their effect on the document text instead. Many of them doesn't
touch the text, so it's useless to send to the other party. As for the
others, the idea is to serialize each one into a string that represent
their textual output. For example, it could be translated to LyX file
syntax itself, couldn't it? The other party would deserialize this
content filling the appropriate LyX data structures. I hope that the
LyX functions for Save and Load could be reused for that matter.

 Now, the hack I did, was rude: keep the serialized LFUN (in form of
 text), send to the other side, reconstruct the LFUN, dispatch it
 locally. INCLUDING CURSOR MOVEMENTS, which are relative (go up, go
 right one char, etc...). That was causing easy de-synch between the
 two sides, about what position the cursor is, when dispatching an
 editing LFUN. So, there should be a way to exchange and keep in synch
 the cursor position independently of the multiple edits being merged
 within the doc.


I had this problem too with my implementation. I could solve it in the
following way: just treat the cursor as a dummy edit and add it to the
bunch. Its position can be updated using the same algorithm I
described.

 Good. Doc revision may be helpful. As highlighted by Nico, if we know
 the revision against which an editing LFUN dispatch was meant, we might
 know what position to affect, but still in case of replay of other users'
 concurrent editing LFUNs, the key point is how to translate/transform
 the subsequent actions..


I claim that the sorting algorithm I loosely described works for that
purpose (maintaining consistency), assuming that all users generate
edits based on the same revision.

 would it be applicable to the nested/structured LyX text, as described
 above ? or, how to extend it properly in such case ?


As I said, it would require proper (de)serialization to a textual format.

 As someone mentioned, when two users are
 editing too close to each other, there is no correct result for this.

 As I see it, if others' cursors are close to mine, then when I start
 typing, LyX should delay a bit the action, so as to ensure I lock
 some part of text where others wouldn't be able to edit. Then, perhaps
 after a time-out I don't edit any more that part, it's released. The
 locked part might be highlighted some-way in the GUI, both for the
 user with the lock (~~green leftbar or similar), and for the one(s)
 without (~~red leftbar or similar).


I agree with Nico here. A lock is not necessary: when someone starts
editing a section, the others will see that and shouldn't interfere.

 knowing what was changed in each revision, it should be possible to
 re-send only the affected/changed parts...


That's a possibility, but one would have to store a history of
revisions in case it is needed by someone else.

Marcelo

Re: GSoC 2013: Interactive LyX

[Liviu Andronic]

On Tue, Apr 30, 2013 at 12:09 AM, Tommaso Cucinotta  wrote:
>> OTOH interactive LyX seems to be really worth and requested feature while the
>> chat looks more like a toy with the aroma of the word "bloat" around (sorry 
>> for
>> the punch :)
>
> I'm not sure here: AFAICS, I'd see myself more needing the chat, for 
> discussing
> ideas with colleagues *live*. The interactive editing is something that 
> crosses
> with version control. I mean, I've been writing papers over CVS, SVN and GIT,
> and I couldn't really see the problem with the classical way of handling the
> interactions and conflicts in these systems. Actually, being capable of 
> handling
> the editing and commits/conflicts resolution *off-line* is valuable as well.
>
I must admit that I share Pavel's sentiment: I'm not sure how much the
community needs/requires a chatting function in LyX. But I was
thinking of possibly a cheap workaround: Why not communicate with
images?

If http://www.lyx.org/trac/ticket/7839 gets included in base LyX, then
it should be much easier to create an LFUN that allows to convert a
document to PDF, pass it through pdfcrop (or similar), transform it
into a bitmap image and copy it to the clipboard. A bit in the style
of Instant Preview. Then the user could insert the resulting image in
any chatting application that supports images (I would suspect Pidgin
does). As a perk we could check if it would be possible to embed the
LyX code that produced the image into the image metadata, and teach
LyX to recognize such metadata: If so, then the receiving user could
insert the image in LyX and LyX would automatically re-integrate the
code into the document.

If an image-based approach is adopted, this would remove the need to
either implement chat in LyX or implement a LyX buffer in a chat
client. Both seem awkward and difficult to achieve.

Anyways, a wild idea. Regards,
Liviu

Re: GSoC 2013: Interactive LyX

[Cyrille Artho]

I must admit that I share Pavel's sentiment: I'm not sure how much the
community needs/requires a chatting function in LyX. But I was
thinking of possibly a cheap workaround: Why not communicate with
images?


Good point. In the age of Skype etc., and with many existing good chat clients,
why implement a new one poorly? Note that collaborative editing is 
different from that, and of course a small chat interface there may be 
useful, but the core would still be collaborative editing.

--
Regards,
Cyrille Artho - http://artho.com/
British education is probably the best in the world, if you can survive
it. If you can't there is nothing left for you but the diplomatic corps.
-- Peter Ustinov

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 08:49, Liviu Andronic wrote:
> But I was
> thinking of possibly a cheap workaround: Why not communicate with
> images?

hmmm.. that sounds like a hack.., would usability be the same ? or the
user would have to switch back and forth among the chat client and lyx
to do this, for handling connection set-up as well as copy'n'paste images
back and forth ?

> Anyways, a wild idea. Regards,

yep..., seems wild :-)!

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 00:23, Nico Williams wrote:
> Well...  If a paragraph is deleted then the pointer might get assigned
> in a subsequent allocation and... you end up with an aliasing problem.

I was thinking of detecting this problem when you delete a par, going through
the cursors/pointers potentially affected, but as you say the criticality is
not local to the LyX instance where the 2 cursors are, that's easy. The problem
is how to synch this forced cursor movement (e.g., going out of the deleted
region, or the incr in pos etc...) with the remote instance in which that
cursor is still editing and get the same outcome in both.

> you don't want to implement a
> distributed locking protocol (for the same reason).

some locking may be the easy way to avoid some of the biggest problems in the 
first instance.
I mean, even with git, there are situations of concurrent edit where the tool 
simply cannot
merge the edits. It has to be done by humans. By locking, you avoid that 
situation to happen.

>  Nor do you want
> to worry about split-brains (netsplits).

pls, explain ?

> Version everything and assign version numbers; keep history.
> Alternatively use hash-of-paragraph-contents as version numbers; keep
> history.

sounds a bit like replicating the git functionality inside lyx, is it 
really needed ?

Let me see: each one keeps a copy of the last edits by everybody, at some point 
the protocol
sorts out the agreed-upon order of the actions, and each client ensures that 
all actions
are played back in the same order (e.g., undo-es the last needed # of actions, 
and replays
them back in the agreed-upon order). Not sure what the GUI (and user-face) 
looks like while
this is happening ... :-), but it might be needed.

T.

Re: GSoC 2013: Interactive LyX

[Liviu Andronic]

On Tue, Apr 30, 2013 at 10:16 AM, Tommaso Cucinotta  wrote:
> On 30/04/13 08:49, Liviu Andronic wrote:
>> But I was
>> thinking of possibly a cheap workaround: Why not communicate with
>> images?
>
> hmmm.. that sounds like a hack.., would usability be the same ? or the
> user would have to switch back and forth among the chat client and lyx
> to do this, for handling connection set-up as well as copy'n'paste images
> back and forth ?
>
Well, it could nicely take the form of a Pidgin plugin:
- The plugin would be communicating to an existing LyX session (set up
a link, etc., to associate a LyX instance/buffer with a chat
conversation window)
- The user would create some material in the LyX buffer (text, image,
formula, what have you)
- By activating an LFUN (button, shortcut) the document would get
compiled, cropped, converted to image (if PDF is not supported in the
chat thingy), Instant Preview-style, and sent to the Pidgin
conversation and directly to the receiving user
- If there is a way to embed LyX code into the PDF/image metadata, the
receiving Pidgin client would allow to press a button and integrate
the received image (more precisely, the embedded code) into an
associated LyX buffer.

I'm no expert, but the basic idea would be to associate two LyX
instances with two chat clients, use PDF/images for rendering complex
LyX content in the chat clients, and additionally/optionally transfer
the code (via a file, as image metadata, etc.) from one LyX instance
via the chat clients to the 2nd LyX instance. Maybe this needs to be
thought through, but all this sounds to me cheap, useful, secure and
achievable during a GSoC project.


>> Anyways, a wild idea. Regards,
>
> yep..., seems wild :-)!
>
I've already got two replies, so maybe there is something to it. :)

Liviu


> T.
>



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Tue, Apr 30, 2013 at 2:49 AM, Liviu Andronic  wrote:
> I must admit that I share Pavel's sentiment: I'm not sure how much the
> community needs/requires a chatting function in LyX. But I was
> thinking of possibly a cheap workaround: Why not communicate with
> images?

LyX doesn't.  Getting through firewalls, networking easily, recommends
it.  It's not about IM (though that would help collaborating authors);
it's about communications using something better than unicast IP
addressing.

Note that LyX could talk to an external program that does all the IM
work, via pipes/socketpairs/whatever IPC.

Nico
--

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Tue, Apr 30, 2013 at 3:26 AM, Tommaso Cucinotta  wrote:
> On 30/04/13 00:23, Nico Williams wrote:
>> Well...  If a paragraph is deleted then the pointer might get assigned
>> in a subsequent allocation and... you end up with an aliasing problem.
>
> I was thinking of detecting this problem when you delete a par, going through
> the cursors/pointers potentially affected, but as you say the criticality is
> not local to the LyX instance where the 2 cursors are, that's easy. The 
> problem
> is how to synch this forced cursor movement (e.g., going out of the deleted
> region, or the incr in pos etc...) with the remote instance in which that
> cursor is still editing and get the same outcome in both.

Right.

>> you don't want to implement a
>> distributed locking protocol (for the same reason).
>
> some locking may be the easy way to avoid some of the biggest problems in the 
> first instance.
> I mean, even with git, there are situations of concurrent edit where the tool 
> simply cannot
> merge the edits. It has to be done by humans. By locking, you avoid that 
> situation to happen.

git. does. not. lock.  (except, in the case of a remote, it locks
briefly around applying commits sent by a client, but what git does
while it holds this lock does not include waiting for I/O from/to any
client.)

Manual merges may be inescapable.  But sometimes you can just avoid it
using brute force.  E.g., one user selects and deletes a paragraph (or
more) while another was typing in that paragraph -> just delete the
paragraphs and make the second user have to click somewhere to get a
cursor back.  AND, a) let the two users bicker over IM :) b) let the
users undo the winning change (the deletion).

I haven't thought through all the possible conflicts scenarios, but I
think that as long as the clients eventually exchange enough messages
you can make them converge.

>>  Nor do you want
>> to worry about split-brains (netsplits).
>
> pls, explain ?

Part of the XMPP/whatever fabric gets disconnected from the rest.  Now
you have two LyX instances collaborating but unable to reach each
other.  What do you do now?  If each user is allowed to keep making
changes that are not acknowledged by the other then conflicts will
pile up, and resolving them will be a mess.  But not letting the users
make progress makes for a poor user experience.

Note that once more, a three-way diff/merge tool for LyX here would be
extremely handy: if two (or more) instances of LyX diverge long enough
because of a split then one user could do a merge and cleanup
conflicts, then push the results to the others.

>> Version everything and assign version numbers; keep history.
>> Alternatively use hash-of-paragraph-contents as version numbers; keep
>> history.
>
> sounds a bit like replicating the git functionality inside lyx, is it 
> really needed ?

Flatly?  Yes.  git doesn't know the semantics of the data it deals
with.  And git's diff/merge doesn't either.  And I suspect that git
diff/merge is not appropriate for merging LyX documents.

> Let me see: each one keeps a copy of the last edits by everybody, at some 
> point the protocol
> sorts out the agreed-upon order of the actions, and each client ensures that 
> all actions
> are played back in the same order (e.g., undo-es the last needed # of 
> actions, and replays
> them back in the agreed-upon order). Not sure what the GUI (and user-face) 
> looks like while
> this is happening ... :-), but it might be needed.

Yes, this.

BUT, you should research what Google and others with online
collaboration do.  I suspect they have it easier: there's only one
instance of the editor and the GUIs (BUIs) are clients of it, in which
case there's no merging to worry about, no netsplits, nada.

For this you could have one instance of LyX act as a master and the
others do everything via the master, in which case the users of the
non-master instance will feel latency (but no worse than with any
other client/server collaboration editors).  This will probably be a
lot easier.

Nico
--

Re: GSoC 2013: Interactive LyX

[Albus X]

Hello. In my opinion, cooperative editing the same paragraph does not
make sense. I will be annoyed if the paragraph I am editing change
from time to time making the structure and meaning and everything a
mess. I suggest that we could simply lock that paragraph while others
can commenting on it, leaving everything to the editor. And the inline
comments act also as a todo list on the editor side, the editor can
tick it when the advice is taken, or reply to explain why not. Every
comment not ticked should be left for the file owner to make a
decision.

On Tue, Apr 30, 2013 at 5:51 PM, Nico Williams  wrote:
> On Tue, Apr 30, 2013 at 3:26 AM, Tommaso Cucinotta  wrote:
>> On 30/04/13 00:23, Nico Williams wrote:
>>> Well...  If a paragraph is deleted then the pointer might get assigned
>>> in a subsequent allocation and... you end up with an aliasing problem.
>>
>> I was thinking of detecting this problem when you delete a par, going through
>> the cursors/pointers potentially affected, but as you say the criticality is
>> not local to the LyX instance where the 2 cursors are, that's easy. The 
>> problem
>> is how to synch this forced cursor movement (e.g., going out of the deleted
>> region, or the incr in pos etc...) with the remote instance in which that
>> cursor is still editing and get the same outcome in both.
>
> Right.
>
>>> you don't want to implement a
>>> distributed locking protocol (for the same reason).
>>
>> some locking may be the easy way to avoid some of the biggest problems in 
>> the first instance.
>> I mean, even with git, there are situations of concurrent edit where the 
>> tool simply cannot
>> merge the edits. It has to be done by humans. By locking, you avoid that 
>> situation to happen.
>
> git. does. not. lock.  (except, in the case of a remote, it locks
> briefly around applying commits sent by a client, but what git does
> while it holds this lock does not include waiting for I/O from/to any
> client.)
>
> Manual merges may be inescapable.  But sometimes you can just avoid it
> using brute force.  E.g., one user selects and deletes a paragraph (or
> more) while another was typing in that paragraph -> just delete the
> paragraphs and make the second user have to click somewhere to get a
> cursor back.  AND, a) let the two users bicker over IM :) b) let the
> users undo the winning change (the deletion).
>
> I haven't thought through all the possible conflicts scenarios, but I
> think that as long as the clients eventually exchange enough messages
> you can make them converge.
>
>>>  Nor do you want
>>> to worry about split-brains (netsplits).
>>
>> pls, explain ?
>
> Part of the XMPP/whatever fabric gets disconnected from the rest.  Now
> you have two LyX instances collaborating but unable to reach each
> other.  What do you do now?  If each user is allowed to keep making
> changes that are not acknowledged by the other then conflicts will
> pile up, and resolving them will be a mess.  But not letting the users
> make progress makes for a poor user experience.
>
> Note that once more, a three-way diff/merge tool for LyX here would be
> extremely handy: if two (or more) instances of LyX diverge long enough
> because of a split then one user could do a merge and cleanup
> conflicts, then push the results to the others.
>
>>> Version everything and assign version numbers; keep history.
>>> Alternatively use hash-of-paragraph-contents as version numbers; keep
>>> history.
>>
>> sounds a bit like replicating the git functionality inside lyx, is it 
>> really needed ?
>
> Flatly?  Yes.  git doesn't know the semantics of the data it deals
> with.  And git's diff/merge doesn't either.  And I suspect that git
> diff/merge is not appropriate for merging LyX documents.
>
>> Let me see: each one keeps a copy of the last edits by everybody, at some 
>> point the protocol
>> sorts out the agreed-upon order of the actions, and each client ensures that 
>> all actions
>> are played back in the same order (e.g., undo-es the last needed # of 
>> actions, and replays
>> them back in the agreed-upon order). Not sure what the GUI (and user-face) 
>> looks like while
>> this is happening ... :-), but it might be needed.
>
> Yes, this.
>
> BUT, you should research what Google and others with online
> collaboration do.  I suspect they have it easier: there's only one
> instance of the editor and the GUIs (BUIs) are clients of it, in which
> case there's no merging to worry about, no netsplits, nada.
>
> For this you could have one instance of LyX act as a master and the
> others do everything via the master, in which case the users of the
> non-master instance will feel latency (but no worse than with any
> other client/server collaboration editors).  This will probably be a
> lot easier.
>
> Nico
> --

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Mon, Apr 29, 2013 at 8:56 PM, Nico Williams  wrote:
> BTW, this has all been solved before (clearly).  Research it and use
> whatever protocol pattern is most appropriate (or, if you can't
> because of patents, invent a new protocol).
>
> Some posts on this list pointed at some such prior work.

I recently implemented a simple collaborative text editor focusing on
maintaining consistency across multiple users edits. I have been
following the discussion about the consistency related issues and
there are indeed several possible approaches. I will try to briefly
describe mine and you can comment about its (in)feasibility.

The main difference is that I was using a coordinating server, but I
believe centralized steps can be turned into distributed ones. The
edits are only of types "insert text" or "delete text", represented as
(global-offset, type, data), where global-offset is the offset from
the beginning of the document (I intentionally avoided dealing with
paragraphs operations explicitly) and data is the inserted string
(including line breaks) or the number of characters to delete from
that position, depending on the edit type.

A "document revision" is a document state (identified by an integer)
which all users know and agree upon. A user state is the latest known
revision and a set of new own edits, in which all offsets are
calculated relative to this last revision. Periodically, the server
asks for creating a new revision in which all users share their own
edits, which can be merged for efficiency (e.g., put many consecutive
insertions/deletions into a single edit). To generate a new revision
from a set of edits, you have to incrementally apply each of them (to
the last revision) sorted by increasing offsets, keeping track of how
many characters you have added/removed so far to be able to pinpoint
the correct location to apply.

The main advantages of this approach are simplicity and avoid dealing
with locking, conflicts, etc. As someone mentioned, when two users are
editing too close to each other, there is no correct result for this.
As a drawback, clients need to keep track of the latest document
revision: if one misses a revision (the user leaves but the document
keeps being edited by others), he should ask someone for the whole
document.

Regards,
Marcelo

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 10:51, Nico Williams wrote:
> Part of the XMPP/whatever fabric gets disconnected from the rest.  Now
> you have two LyX instances collaborating but unable to reach each
> other.  What do you do now?  If each user is allowed to keep making
> changes that are not acknowledged by the other then conflicts will
> pile up, and resolving them will be a mess.  But not letting the users
> make progress makes for a poor user experience.

Guess everybody would love to be able to keep editing, and saving locally
their changes, so that next time (the day after) the other user comes back
on-line, things can synch-up again. But, that sounds a lot like version
control (again), rather than interactive editing.

If it has to be interactive editing, then perhaps stopping the user is the
right thing to do ?

Or, as you said, we actually need a lyx-aware version control system that
is capable of merging edits, and also 

> Note that once more, a three-way diff/merge tool for LyX here would be
> extremely handy: if two (or more) instances of LyX diverge long enough
> because of a split then one user could do a merge and cleanup
> conflicts, then push the results to the others.

... and also being capable of triggering a compare panel (Compare Document
might be re-used here ?) where the user sorts out conflicts.

> For this you could have one instance of LyX act as a master and the
> others do everything via the master, in which case the users of the
> non-master instance will feel latency (but no worse than with any
> other client/server collaboration editors).  This will probably be a
> lot easier.

You mean, edits actually happen only on the master, and each client/slave
only sees updates as reflected and serialized by the master ? yes, a lot
easier, but perhaps very slow/unusable over the Internet.

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 21:12, Marcelo Galvão Póvoa wrote:
> there are indeed several possible approaches. I will try to briefly
> describe mine and you can comment about its (in)feasibility.

As you say, your case was far easier, and it seems to correspond to the
simple scenario of editing text in a text-only paragraph.
Criticalities already discussed on the list: keep position as an offset,
it's basically what LyX does, but in a structured form. A Cursor is a
stack of CursorSlice, where each slice is basically a triplet

  

where pos indicates the character position in the text, pit (ParagraphIT)
indicates the paragraph number in the multi-paragraph text, idx indicates
what cell of a multi-cell table we're in. Then, we have a stack of these,
because in a given pos we might have, instead of a normal character, a
kind of placeholder indicating there's an inset there. So, we go to the
inset, which in turn is another kind-of LyX text, with potentially its
own multi-paragraph text etc

So, another user edits creating further pars or deleting pars, and we
need to pay attention to cursor positions after them.

> edits are only of types "insert text" or "delete text", represented as
> (global-offset, type, data),

pls, have a look at LyXAction.cpp to get a feeling of the possible edit
actions that users might be willing to do (I'm not pretending that all
of them should work in the interactive editing mode -- perhaps we just
allow a subset of them to be used in that mode; ideally, we'd like all
of them to keep working).

Now, the hack I did, was rude: keep the serialized LFUN (in form of
text), send to the other side, reconstruct the LFUN, dispatch it
locally. INCLUDING CURSOR MOVEMENTS, which are relative (go up, go
right one char, etc...). That was causing easy de-synch between the
two sides, about what position the cursor is, when dispatching an
editing LFUN. So, there should be a way to exchange and keep in synch
the cursor position independently of the multiple edits being merged
within the doc.

That's why sb. proposed to use par hashes to identify the par, or global
unique identifiers, etc We all know how a version control system
does that, by the +/- 3 lines around the edit..., and we know the
limitation of such an approach. What can we do in such case ?

> A "document revision" is a document state (identified by an integer)

Good. Doc revision may be helpful. As highlighted by Nico, if we know
the revision against which an editing LFUN dispatch was meant, we might
know what position to affect, but still in case of replay of other users'
concurrent editing LFUNs, the key point is how to translate/transform
the subsequent actions..

> The main advantages of this approach are simplicity and avoid dealing
> with locking, conflicts, etc.

would it be applicable to the nested/structured LyX text, as described
above ? or, how to extend it properly in such case ?

> As someone mentioned, when two users are
> editing too close to each other, there is no correct result for this.

As I see it, if others' cursors are close to mine, then when I start
typing, LyX should delay a bit the action, so as to ensure I "lock"
some part of text where others wouldn't be able to edit. Then, perhaps
after a time-out I don't edit any more that part, it's released. The
locked part might be highlighted some-way in the GUI, both for the
user with the lock (~~green leftbar or similar), and for the one(s)
without (~~red leftbar or similar).

Just thinking aloud, it might be extremely handy to have a chat pane
for being able to discuss about the doc while editing, w/out typing
the stuff straight into the doc :-)!

In the end, I keep seeing lots of relations within the two projects,
with possibly the chat being a part of the overall collaboration
features.

> As a drawback, clients need to keep track of the latest document
> revision: if one misses a revision (the user leaves but the document
> keeps being edited by others), he should ask someone for the whole
> document.

knowing what was changed in each revision, it should be possible to
re-send only the affected/changed parts...

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Tue, Apr 30, 2013 at 3:41 PM, Tommaso Cucinotta  wrote:
> On 30/04/13 10:51, Nico Williams wrote:
>> Part of the XMPP/whatever fabric gets disconnected from the rest.  Now
>> you have two LyX instances collaborating but unable to reach each
>> other.  What do you do now?  If each user is allowed to keep making
>> changes that are not acknowledged by the other then conflicts will
>> pile up, and resolving them will be a mess.  But not letting the users
>> make progress makes for a poor user experience.
>
> Guess everybody would love to be able to keep editing, and saving locally
> their changes, so that next time (the day after) the other user comes back
> on-line, things can synch-up again. But, that sounds a lot like version
> control (again), rather than interactive editing.

What's wrong with version control?  In fact, re-use the existing
change tracking UI but add colors or labels to identify authors.  On
conflict just pick a winner (deterministically) and the loser will
notice (or better: be told).

Locking will. not. work. well.   Maybe I'm being too categorical
but... all my experience says locking won't work.

> If it has to be interactive editing, then perhaps stopping the user is the
> right thing to do ?

I've used a few interactive online collaborative editors before.  Not
one locked a user out of a paragraph/section/whatever.  I can't
imagine being pleased with a UI that required the user be aware of
locks, even if only in the case of being locked out.

OTOH, consider the online editors I've seen (like, e.g., Google docs).
 You generally get to see other users' cursors and typing almost in
real-time if your window has the relevant document sections in view.
The very appearance of another user's cursor in a paragraph that
you're editing should be enough for you to pop up an IM to the other
saying "hands-off man, I'm doing some major surgery on the paragraph".
 This only fails in the case of netsplits.  Now, if one editor is
considered a master then the peers that are cut-off from it will stop
editing; while if all editors are equal and the whole process is truly
distributed and peer-to-peer, then you absolutely need either
deterministic conflict resolution (in some cases destructive) or
manual conflict merges.

I think the latter is a much better user experience.  Users know how
to talk to each other and arbitrate who works on what.

> Or, as you said, we actually need a lyx-aware version control system that
> is capable of merging edits, and also 

But you might be able to avoid having to bite that bullet.  But if you
do bite this bullet, the rest of us will be oh-so-happy.

>> Note that once more, a three-way diff/merge tool for LyX here would be
>> extremely handy: if two (or more) instances of LyX diverge long enough
>> because of a split then one user could do a merge and cleanup
>> conflicts, then push the results to the others.
>
> ... and also being capable of triggering a compare panel (Compare Document
> might be re-used here ?) where the user sorts out conflicts.

Maybe.  But see above.

>> For this you could have one instance of LyX act as a master and the
>> others do everything via the master, in which case the users of the
>> non-master instance will feel latency (but no worse than with any
>> other client/server collaboration editors).  This will probably be a
>> lot easier.
>
> You mean, edits actually happen only on the master, and each client/slave
> only sees updates as reflected and serialized by the master ? yes, a lot
> easier, but perhaps very slow/unusable over the Internet.

Yes.  Well, no, it works for Google and others.  Over an XMPP fabric
it should work fine too.  On netsplit the non-master peers cut-off
from the master can stop allowing local edits, or fallback on conflict
resolution later when the netsplit is resolved.

Offline collaboration (e.g., online when I'm not on an airplane,
offline when I am) would be wonderful, and this is where true 3-way
diff/merge with LyX semantics would be awesome.

Nico
--

Re: GSoC 2013: Interactive LyX

[Marcelo Galvão Póvoa]

On Tue, Apr 30, 2013 at 6:06 PM, Tommaso Cucinotta  wrote:
> On 30/04/13 21:12, Marcelo Galvăo Póvoa wrote:
>> there are indeed several possible approaches. I will try to briefly
>> describe mine and you can comment about its (in)feasibility.
>
> As you say, your case was far easier, and it seems to correspond to the
> simple scenario of editing text in a text-only paragraph.
> Criticalities already discussed on the list: keep position as an offset,
> it's basically what LyX does, but in a structured form. A Cursor is a
> stack of CursorSlice, where each slice is basically a triplet
>
>   
>
> where pos indicates the character position in the text, pit (ParagraphIT)
> indicates the paragraph number in the multi-paragraph text, idx indicates
> what cell of a multi-cell table we're in. Then, we have a stack of these,
> because in a given pos we might have, instead of a normal character, a
> kind of placeholder indicating there's an inset there. So, we go to the
> inset, which in turn is another kind-of LyX text, with potentially its
> own multi-paragraph text etc
>
> So, another user edits creating further pars or deleting pars, and we
> need to pay attention to cursor positions after them.
>
>> edits are only of types "insert text" or "delete text", represented as
>> (global-offset, type, data),
>
> pls, have a look at LyXAction.cpp to get a feeling of the possible edit
> actions that users might be willing to do (I'm not pretending that all
> of them should work in the interactive editing mode -- perhaps we just
> allow a subset of them to be used in that mode; ideally, we'd like all
> of them to keep working).
>

I think the best approach is not treating the LFUN as edits themselves
but their effect on the document text instead. Many of them doesn't
touch the text, so it's useless to send to the other party. As for the
others, the idea is to serialize each one into a string that represent
their textual output. For example, it could be translated to LyX file
syntax itself, couldn't it? The other party would deserialize this
content filling the appropriate LyX data structures. I hope that the
LyX functions for Save and Load could be reused for that matter.

> Now, the hack I did, was rude: keep the serialized LFUN (in form of
> text), send to the other side, reconstruct the LFUN, dispatch it
> locally. INCLUDING CURSOR MOVEMENTS, which are relative (go up, go
> right one char, etc...). That was causing easy de-synch between the
> two sides, about what position the cursor is, when dispatching an
> editing LFUN. So, there should be a way to exchange and keep in synch
> the cursor position independently of the multiple edits being merged
> within the doc.
>

I had this problem too with my implementation. I could solve it in the
following way: just treat the cursor as a dummy edit and add it to the
bunch. Its position can be updated using the same algorithm I
described.

> Good. Doc revision may be helpful. As highlighted by Nico, if we know
> the revision against which an editing LFUN dispatch was meant, we might
> know what position to affect, but still in case of replay of other users'
> concurrent editing LFUNs, the key point is how to translate/transform
> the subsequent actions..
>

I claim that the sorting algorithm I loosely described works for that
purpose (maintaining consistency), assuming that all users generate
edits based on the same revision.

> would it be applicable to the nested/structured LyX text, as described
> above ? or, how to extend it properly in such case ?
>

As I said, it would require proper (de)serialization to a textual format.

>> As someone mentioned, when two users are
>> editing too close to each other, there is no correct result for this.
>
> As I see it, if others' cursors are close to mine, then when I start
> typing, LyX should delay a bit the action, so as to ensure I "lock"
> some part of text where others wouldn't be able to edit. Then, perhaps
> after a time-out I don't edit any more that part, it's released. The
> locked part might be highlighted some-way in the GUI, both for the
> user with the lock (~~green leftbar or similar), and for the one(s)
> without (~~red leftbar or similar).
>

I agree with Nico here. A lock is not necessary: when someone starts
editing a section, the others will see that and shouldn't interfere.

> knowing what was changed in each revision, it should be possible to
> re-send only the affected/changed parts...
>

That's a possibility, but one would have to store a history of
revisions in case it is needed by someone else.

Marcelo

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 21/04/13 20:56, Pavel Sanda wrote:
 lyx internals, as you say, multiple Cursors, or as said in some other 
 thread, if
 we should switch from index-based to ptr-based CursorSlice, etc...
 
 I'm pessimist that newcomer in the project should start substantial 
 cursorslice
 refactoring. There are so many corners to know about and anyone responsible
 for deeper changes should be around for longer time than just one summer.

The alternative is to not re-factor Cursor[Slice], but rather add the code that
ensures consistency.

For example, if I press Enter and I add a paragraph here, then all cursors with 
pit
\gt than the one I'm into should get a ++pit. This can be done without 
refactoring,
simply run over all the cursors and make them consistent.
Similar with the `pos' if I'm typing/inserting and there are cursors ahead of 
me in
the same line/paragraph.

This cursor consistency will have to be specified better when doing cut/delete 
of
segments with other cursors inside the affected region.

Such an approach would not run the risk to affect stability of LyX. If the 
consistency
logic has any flaw, they would show up only in the interactive editing session, 
not
during normal use.

 OTOH interactive LyX seems to be really worth and requested feature while the
 chat looks more like a toy with the aroma of the word bloat around (sorry 
 for
 the punch :) 

I'm not sure here: AFAICS, I'd see myself more needing the chat, for discussing
ideas with colleagues *live*. The interactive editing is something that crosses
with version control. I mean, I've been writing papers over CVS, SVN and GIT,
and I couldn't really see the problem with the classical way of handling the
interactions and conflicts in these systems. Actually, being capable of handling
the editing and commits/conflicts resolution *off-line* is valuable as well.

With interactive editing, everyone is excited about the idea that it might be
a LyX-enhanced Google Docs, however in Docs there's a server with the document
always available where I can connect, get the updates and keep editing. If we
have an interactive server-less lyx-to-lyx editor, then you'll need the party
to be on-line for editing the document. Or, where do you imagine the document
to be kept ? Or, if I can edit locally/disconnected, then synchronize with the
other party when getting connected, isn't that ... ehm... already there, and
called version control :-) ?

Is it so important to have sophisticated conflict management algos for handling
concurrent edits that happen so close to each other ? In those cases, AFAICS,
you want to say the others: hey, stop for a moment, I'm going over this part
now! and you don't want them to mess up what you're just writing close
to where you're editing. Otherwise, no software can really understand what each
one wants to modify and how these concurrent writes should inter-mix and come
up with something that still makes sense :-).

Concerning the risk of bloating LyX, one way could be to keep the LyX chat 
and/or
interactive editor as a separate executable(s), that starts up with a customised
view showing the contacts list etc

However, both in the chat and in the interactive lyx proposals, I see the 
contacts
and connection part as essential for usability. If it's a pain to set-it-up, and
users have to learn about static/dynamic IPs, TCP/IP ports, port forwarding, 
then
nobody will ever use it. If it's as easy as connecting with Skype or gtalk, then
it will be used.

Bye,

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Sat, Apr 20, 2013 at 7:06 AM, Vinícius dos Santos Oliveira
vini.ipsma...@gmail.com wrote:
 2013/4/20 Tommaso Cucinotta tomm...@lyx.org

 3) client-side encryption add-on: can we exchange b64 encoding of
 client-side
encrypted text segments, so that IM servers cannot see what's being
 exchanged ?


 It's possible to use OTR:
 http://en.wikipedia.org/wiki/Off-the-Record_Messaging

Yes.  Let libpurple (or similar) take care of this for you.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Sat, Apr 20, 2013 at 5:33 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
 Concerning the interactive editing, I also remembered some critical issues 
 faced
 during my prior quick hack: LyX internally uses index positions for the 
 cursor,
 i.e., my cursor is on the 3rd paragraph, 5th character, and in case of insets 
 it
 goes recursively down the hierarchy.

 However, when considering that other users might be editing stuff 
 above/before our
 cursor position, then it means this way of referencing positions within the 
 text
 should be changed/reworked to a pointer-based one.

But what alternative addressing schemes could there be?  I'm thinking
of a hash-based scheme, something like {{hash of paragraph contents},
offset into paragraph.  Now if two or more users edit different
paragraphs each concurrently, all's good; if a paragraph gets moved
(cut-n-pasted) elsewhere then pointers into it don't change; and if
two or more users edit the same paragraph then... each running LyX
will have to keep history so they can find a paragraph by old hash,
then from there find the new version.  This seems a bit fragile, and
it might be better to instead assign paragraphs globally-unique IDs
using a local prefix and a random number, then we get the same
behavior as with a hash but we don't have to worry about collisions or
the like -- OTOH moving by cut-n-paste requires extra logic to
preserve the paragraph ID.

Nico
--

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 20/04/13 10:19, Tommaso Cucinotta wrote:
 So, as I said
 earlier, since the project already seems quite large as is, it would
 be better to discuss a list of deliverables for the GSoC and how they
 should be implemented.
 
 As for intermediate checkpoints within the project, for the chat:
 1) minimal GUI panel within LyX for login and friends selection within
some of these IM systems (things like searching for and adding friends
may be handled through an external client -- in LyX we just need to
see who is online and start chatting)
 2) chat functionality; it might be interesting to investigate on keeping
compatibility with text-only clients, i.e., one chats in LyX the other
sees and writes LaTeX :-)
 3) client-side encryption add-on: can we exchange b64 encoding of client-side
encrypted text segments, so that IM servers cannot see what's being 
 exchanged ?
 
 As for the more challenging interactive lyx project, I'm not sure any of these
 pre-existing IM infrastructures are appropriate, the key issue being how long
 a message takes to be delivered to the destination. For IM chats, I wouldn't
 expect a server to hurry up in delivering msgs. But it also depends on what
 functionality and extensibility options are there in these extensible 
 protocols.

For the interactive lyx we might go target lyx-to-lyx at the beginning, for 
sorting
out the collaborative editing core part of the feature, then add the pane with
list of users and/or shared documents, and setting up connection etc... as a 
further
work item, to be preceded by rough trials of using any of these protocols (e.g.,
xmpp through qxmpp -- http://code.google.com/p/qxmpp/ -- seems a reasonable way 
to go)
for end-to-end exchanges and see what latency we get, if it's acceptable etc..

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 29/04/13 23:32, Nico Williams wrote:
 However, when considering that other users might be editing stuff 
 above/before our
 cursor position, then it means this way of referencing positions within the 
 text
 should be changed/reworked to a pointer-based one.
 
 But what alternative addressing schemes could there be?

well, when I wrote pointer, I actually meant C/C++ pointer :-). It's fixed,
it doesn't change, it simply refs the paragraph, regardless of what other
paragraphs precede it, or whether it is moved around (ParagraphList is a
list, isn't it ?)
Now, the problem comes when deleting a paragraph: we need to check that no
other cursors are on it, otherwise either forbid the operation or move the
other cursors at the end of the removed part.

Further issue is characters, as there's no list of characters in LyX, AFAICR,
but it's a contiguous array. So, for chars there seems to be no other way
than keeping a pos index..., or reworking that as a CharacterList.{h,cpp},
which I'm quite sure somebody wouldn't like.

Given also issues raised in that a newcomer should not be messing around the
core of LyX and refactor the cursor, because of the risk of entering a
stability nightmare, it may be valuable to consider to keep the cursor as
it is, and instead add the necessary logic to modify affected cursors of
other concurrent editors consistently with the action.

For example:
-) when inserting a new character (LFUN_SELF_INSERT):
   for each cursor in same par in positions beyond this, do a pos++
-) when inserting a new par (on Enter):
   for each cursor in later pars, do a pit++
-) others for cut'n'paste, etc...
-) I know, cases will grow fast...

 I'm thinking
 of a hash-based scheme, something like {{hash of paragraph contents},
 offset into paragraph.

while extremely git-ish :-), it would have the problem of identical paragraphs
that are very possible in documents (e.g., right after a copy'n'paste).

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 29/04/13 23:26, Nico Williams wrote:
 It's possible to use OTR:
 http://en.wikipedia.org/wiki/Off-the-Record_Messaging
 
 Yes.  Let libpurple (or similar) take care of this for you.

Are you aware of a similar library for Qt-oriented projects ?
Any comment on, or experience with, qxmpp -- http://code.google.com/p/qxmpp/ ?

Do we really need a multi-protocol library such as libpurple (or equivalent 
functionality in Kopete), or can we be reasonably fine with xmpp ?

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Mon, Apr 29, 2013 at 6:06 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 29/04/13 23:26, Nico Williams wrote:
 It's possible to use OTR:
 http://en.wikipedia.org/wiki/Off-the-Record_Messaging

 Yes.  Let libpurple (or similar) take care of this for you.

 Are you aware of a similar library for Qt-oriented projects ?
 Any comment on, or experience with, qxmpp -- http://code.google.com/p/qxmpp/ ?

 Do we really need a multi-protocol library such as libpurple (or equivalent 
 functionality in Kopete), or can we be reasonably fine with xmpp ?

You can be fine with XMPP.  But do you want to reuse an OTR
implementation?  You should, just as you should want to reuse an XMPP
implementation.  Any such library with a suitable API and license
should do.  No, I don't know which exist or which to recommend :(

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 00:06, Tommaso Cucinotta wrote:
 Any comment on, or experience with, qxmpp -- http://code.google.com/p/qxmpp/ ?

This can be useful for applicants to look at

  
http://doc.qxmpp.org/qxmpp-snapshot/classQXmppRosterManager.html#a978cf900248b0ef144460bb52052ded8

to get a feeling of how easy it is to manage these friends lists with a 
framework like this.
Instantiating a QXmppClient (or a subclass) within LyX, connecting the needed 
signals, and
adding a simple pane showing the list of users (roasters?) should be 
straightforward.

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 00:11, Nico Williams wrote:
 But do you want to reuse an OTR
 implementation?

The question is why OTR, but perhaps the answer is simply that is already made 
to be compatible with messaging protocols.

However, security may be one of the optional add-on / separate work-items / 
fine things we do if we get everything else working properly.

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Mon, Apr 29, 2013 at 6:03 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 29/04/13 23:32, Nico Williams wrote:
 However, when considering that other users might be editing stuff 
 above/before our
 cursor position, then it means this way of referencing positions within the 
 text
 should be changed/reworked to a pointer-based one.

 But what alternative addressing schemes could there be?

 well, when I wrote pointer, I actually meant C/C++ pointer :-). It's fixed,
 it doesn't change, it simply refs the paragraph, regardless of what other
 paragraphs precede it, or whether it is moved around (ParagraphList is a
 list, isn't it ?)

Well...  If a paragraph is deleted then the pointer might get assigned
in a subsequent allocation and... you end up with an aliasing problem.

I strongly recommend instead that you have a paragraph ID (call it
pointer if you like), saved in .lyx (this is important), and
consisting of two things:

 - a local LyX/host/whatever instance ID (can be re-generated every
time LyX starts)

 - a paragraph ID that is assigned (and saved in the .lyx!) when the
paragraph is created (if an old .lyx doesn't have this... then assign
one at open / conversion time).

 Now, the problem comes when deleting a paragraph: we need to check that no
 other cursors are on it, otherwise either forbid the operation or move the
 other cursors at the end of the removed part.

You can't do that.  Assume chat servers/peers come and go.  You don't
want to wait potentially forever, and you don't want to implement a
distributed locking protocol (for the same reason).  Nor do you want
to worry about split-brains (netsplits).

 Further issue is characters, as there's no list of characters in LyX, AFAICR,
 but it's a contiguous array. So, for chars there seems to be no other way
 than keeping a pos index..., or reworking that as a CharacterList.{h,cpp},
 which I'm quite sure somebody wouldn't like.

Version everything and assign version numbers; keep history.
Alternatively use hash-of-paragraph-contents as version numbers; keep
history.

 Given also issues raised in that a newcomer should not be messing around the
 core of LyX and refactor the cursor, because of the risk of entering a
 stability nightmare, it may be valuable to consider to keep the cursor as
 it is, and instead add the necessary logic to modify affected cursors of
 other concurrent editors consistently with the action.

 For example:
 -) when inserting a new character (LFUN_SELF_INSERT):
for each cursor in same par in positions beyond this, do a pos++
 -) when inserting a new par (on Enter):
for each cursor in later pars, do a pit++
 -) others for cut'n'paste, etc...
 -) I know, cases will grow fast...

See above.  You can't really synchronize this way.

Instead you want to have each LyX instance see something like a stream
of events, some locally-generated, some not.  You can get out of sync
with such a scheme, but i think you can arrange (by keeping enough
history) to resolve conflicts deterministically to end up with the
same content.  However, if two or more LyX instances continue to edit
for long enough through a netsplit then you may have to have the users
merge conflicting paragraphs.

 I'm thinking
 of a hash-based scheme, something like {{hash of paragraph contents},
 offset into paragraph.

 while extremely git-ish :-), it would have the problem of identical paragraphs
 that are very possible in documents (e.g., right after a copy'n'paste).

Assigning a globally-unique paragraph ID on paragraph create is safer.
 But LyX could easily allow a paragraph to have copies in multiple
places in the same doc either way, but it's all much easier with
globally-unique paragraph IDs.

Nico
--

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Mon, Apr 29, 2013 at 6:21 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 30/04/13 00:11, Nico Williams wrote:
 But do you want to reuse an OTR
 implementation?

 The question is why OTR, but perhaps the answer is simply that is already 
 made to be compatible with messaging protocols.

OTR is the only open protocol that exists today for end-to-end
authenticated encryption over IM.  There's also Apple's iMessage, but
that's proprietary.  Neither XMPP, nor AIM, nor IRC, ... provide the
same feature.  Hmmm, I may tell a lie: there's also SILC, but I know
little about it and it's very niche.

Merely using XMPP with TLS does not provide end-to-end security.

Mind you, even with OTR, most users never bother authenticating each
other, I think, and so they end up with potential men-in-the-middle
(MITMs).  But at least they can authenticate (and detect the MITMs),
and if they don't they still get protection from passive
eavesdroppers, no matter what the XMPP fabric does in the middle.

 However, security may be one of the optional add-on / separate work-items / 
 fine things we do if we get everything else working properly.

Right, but if you use a library that already has OTR then you're good
to go.  Well, that's another lie: you still need to provide a UI for
OTR, but that goes with using XMPP (or whatever) in the first place
too.

Nico
--

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 00:03, Tommaso Cucinotta wrote:
 For example:
 -) when inserting a new character (LFUN_SELF_INSERT):
for each cursor in same par in positions beyond this, do a pos++
 -) when inserting a new par (on Enter):
for each cursor in later pars, do a pit++
 -) others for cut'n'paste, etc...
 -) I know, cases will grow fast...

-) when adding a column and/or row, do a _idx += whatever-needed,
   to achieve the equivalent ++row() or ++col() ?

-) handle correspondingly the delete cases and decrement as needed.

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

BTW, this has all been solved before (clearly).  Research it and use
whatever protocol pattern is most appropriate (or, if you can't
because of patents, invent a new protocol).

Some posts on this list pointed at some such prior work.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 21/04/13 20:56, Pavel Sanda wrote:
>> lyx internals, as you say, multiple Cursors, or as said in some other 
>> thread, if
>> we should switch from index-based to ptr-based CursorSlice, etc...
> 
> I'm pessimist that newcomer in the project should start substantial 
> cursorslice
> refactoring. There are so many corners to know about and anyone responsible
> for deeper changes should be around for longer time than just one summer.

The alternative is to not re-factor Cursor[Slice], but rather add the code that
ensures consistency.

For example, if I press Enter and I add a paragraph here, then all cursors with 
pit
\gt than the one I'm into should get a ++pit. This can be done without 
refactoring,
simply run over all the cursors and make them consistent.
Similar with the `pos' if I'm typing/inserting and there are cursors ahead of 
me in
the same line/paragraph.

This cursor consistency will have to be specified better when doing cut/delete 
of
segments with other cursors inside the affected region.

Such an approach would not run the risk to affect stability of LyX. If the 
consistency
logic has any flaw, they would show up only in the interactive editing session, 
not
during normal use.

> OTOH interactive LyX seems to be really worth and requested feature while the
> chat looks more like a toy with the aroma of the word "bloat" around (sorry 
> for
> the punch :) 

I'm not sure here: AFAICS, I'd see myself more needing the chat, for discussing
ideas with colleagues *live*. The interactive editing is something that crosses
with version control. I mean, I've been writing papers over CVS, SVN and GIT,
and I couldn't really see the problem with the classical way of handling the
interactions and conflicts in these systems. Actually, being capable of handling
the editing and commits/conflicts resolution *off-line* is valuable as well.

With interactive editing, everyone is excited about the idea that it might be
a LyX-enhanced Google Docs, however in Docs there's a server with the document
always available where I can connect, get the updates and keep editing. If we
have an interactive server-less lyx-to-lyx editor, then you'll need the party
to be on-line for editing the document. Or, where do you imagine the document
to be kept ? Or, if I can edit locally/disconnected, then synchronize with the
other party when getting connected, isn't that ... ehm... already there, and
called version control :-) ?

Is it so important to have sophisticated conflict management algos for handling
concurrent edits that happen so close to each other ? In those cases, AFAICS,
you want to say the others: "hey, stop for a moment, I'm going over this part
now!" and you don't want them to mess up what you're just writing close
to where you're editing. Otherwise, no software can really understand what each
one wants to modify and how these concurrent writes should inter-mix and come
up with something that still makes sense :-).

Concerning the risk of bloating LyX, one way could be to keep the LyX chat 
and/or
interactive editor as a separate executable(s), that starts up with a customised
view showing the contacts list etc

However, both in the chat and in the interactive lyx proposals, I see the 
contacts
and connection part as essential for usability. If it's a pain to set-it-up, and
users have to learn about static/dynamic IPs, TCP/IP ports, port forwarding, 
then
nobody will ever use it. If it's as easy as connecting with Skype or gtalk, then
it will be used.

Bye,

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Sat, Apr 20, 2013 at 7:06 AM, Vinícius dos Santos Oliveira
 wrote:
> 2013/4/20 Tommaso Cucinotta 
>>
>> 3) client-side encryption add-on: can we exchange b64 encoding of
>> client-side
>>encrypted text segments, so that IM servers cannot see what's being
>> exchanged ?
>
>
> It's possible to use OTR:
> http://en.wikipedia.org/wiki/Off-the-Record_Messaging

Yes.  Let libpurple (or similar) take care of this for you.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Sat, Apr 20, 2013 at 5:33 AM, Tommaso Cucinotta  wrote:
> Concerning the interactive editing, I also remembered some critical issues 
> faced
> during my prior quick hack: LyX internally uses index positions for the 
> cursor,
> i.e., my cursor is on the 3rd paragraph, 5th character, and in case of insets 
> it
> goes recursively down the hierarchy.
>
> However, when considering that other users might be editing stuff 
> above/before our
> cursor position, then it means this way of referencing positions within the 
> text
> should be changed/reworked to a pointer-based one.

But what alternative addressing schemes could there be?  I'm thinking
of a hash-based scheme, something like {{hash of paragraph contents},
offset into paragraph.  Now if two or more users edit different
paragraphs each concurrently, all's good; if a paragraph gets moved
(cut-n-pasted) elsewhere then pointers into it don't change; and if
two or more users edit the same paragraph then... each running LyX
will have to keep history so they can find a paragraph by old hash,
then from there find the new version.  This seems a bit fragile, and
it might be better to instead assign paragraphs globally-unique IDs
using a local prefix and a random number, then we get the same
behavior as with a hash but we don't have to worry about collisions or
the like -- OTOH moving by cut-n-paste requires extra logic to
preserve the paragraph ID.

Nico
--

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 20/04/13 10:19, Tommaso Cucinotta wrote:
>> So, as I said
>> earlier, since the project already seems quite large as is, it would
>> be better to discuss a list of deliverables for the GSoC and how they
>> should be implemented.
> 
> As for intermediate checkpoints within the project, for the chat:
> 1) minimal GUI panel within LyX for login and friends selection within
>some of these IM systems (things like searching for and adding friends
>may be handled through an external client -- in LyX we just need to
>see who is online and start chatting)
> 2) chat functionality; it might be interesting to investigate on keeping
>compatibility with text-only clients, i.e., one chats in LyX the other
>sees and writes LaTeX :-)
> 3) client-side encryption add-on: can we exchange b64 encoding of client-side
>encrypted text segments, so that IM servers cannot see what's being 
> exchanged ?
> 
> As for the more challenging interactive lyx project, I'm not sure any of these
> pre-existing IM infrastructures are appropriate, the key issue being how long
> a message takes to be delivered to the destination. For IM chats, I wouldn't
> expect a server to hurry up in delivering msgs. But it also depends on what
> functionality and extensibility options are there in these extensible 
> protocols.

For the interactive lyx we might go target lyx-to-lyx at the beginning, for 
sorting
out the collaborative editing "core" part of the feature, then add the pane with
list of users and/or shared documents, and setting up connection etc... as a 
further
work item, to be preceded by rough trials of using any of these protocols (e.g.,
xmpp through qxmpp -- http://code.google.com/p/qxmpp/ -- seems a reasonable way 
to go)
for end-to-end exchanges and see what latency we get, if it's acceptable etc..

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 29/04/13 23:32, Nico Williams wrote:
>> However, when considering that other users might be editing stuff 
>> above/before our
>> cursor position, then it means this way of referencing positions within the 
>> text
>> should be changed/reworked to a pointer-based one.
> 
> But what alternative addressing schemes could there be?

well, when I wrote pointer, I actually meant C/C++ pointer :-). It's fixed,
it doesn't change, it simply refs the paragraph, regardless of what other
paragraphs precede it, or whether it is moved around (ParagraphList is a
list, isn't it ?)
Now, the problem comes when deleting a paragraph: we need to check that no
other cursors are on it, otherwise either forbid the operation or move the
other cursors at the end of the removed part.

Further issue is characters, as there's no list of characters in LyX, AFAICR,
but it's a contiguous array. So, for chars there seems to be no other way
than keeping a pos index..., or reworking that as a CharacterList.{h,cpp},
which I'm quite sure somebody wouldn't like.

Given also issues raised in that a newcomer should not be messing around the
core of LyX and refactor the cursor, because of the risk of entering a
stability nightmare, it may be valuable to consider to keep the cursor as
it is, and instead add the necessary logic to modify affected cursors of
other concurrent editors consistently with the action.

For example:
-) when inserting a new character (LFUN_SELF_INSERT):
   for each cursor in same par in positions beyond this, do a pos++
-) when inserting a new par (on Enter):
   for each cursor in later pars, do a pit++
-) others for cut'n'paste, etc...
-) I know, cases will grow fast...

> I'm thinking
> of a hash-based scheme, something like {{hash of paragraph contents},
> offset into paragraph.

while extremely git-ish :-), it would have the problem of identical paragraphs
that are very possible in documents (e.g., right after a copy'n'paste).

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 29/04/13 23:26, Nico Williams wrote:
>> It's possible to use OTR:
>> http://en.wikipedia.org/wiki/Off-the-Record_Messaging
> 
> Yes.  Let libpurple (or similar) take care of this for you.

Are you aware of a similar library for Qt-oriented projects ?
Any comment on, or experience with, qxmpp -- http://code.google.com/p/qxmpp/ ?

Do we really need a multi-protocol library such as libpurple (or equivalent 
functionality in Kopete), or can we be reasonably fine with xmpp ?

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Mon, Apr 29, 2013 at 6:06 PM, Tommaso Cucinotta  wrote:
> On 29/04/13 23:26, Nico Williams wrote:
>>> It's possible to use OTR:
>>> http://en.wikipedia.org/wiki/Off-the-Record_Messaging
>>
>> Yes.  Let libpurple (or similar) take care of this for you.
>
> Are you aware of a similar library for Qt-oriented projects ?
> Any comment on, or experience with, qxmpp -- http://code.google.com/p/qxmpp/ ?
>
> Do we really need a multi-protocol library such as libpurple (or equivalent 
> functionality in Kopete), or can we be reasonably fine with xmpp ?

You can be fine with XMPP.  But do you want to reuse an OTR
implementation?  You should, just as you should want to reuse an XMPP
implementation.  Any such library with a suitable API and license
should do.  No, I don't know which exist or which to recommend :(

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 00:06, Tommaso Cucinotta wrote:
> Any comment on, or experience with, qxmpp -- http://code.google.com/p/qxmpp/ ?

This can be useful for applicants to look at

  
http://doc.qxmpp.org/qxmpp-snapshot/classQXmppRosterManager.html#a978cf900248b0ef144460bb52052ded8

to get a feeling of how easy it is to manage these friends lists with a 
framework like this.
Instantiating a QXmppClient (or a subclass) within LyX, connecting the needed 
signals, and
adding a simple pane showing the list of users (roasters?) should be 
straightforward.

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 00:11, Nico Williams wrote:
> But do you want to reuse an OTR
> implementation?

The question is why OTR, but perhaps the answer is simply that is already made 
to be compatible with messaging protocols.

However, security may be one of the optional add-on / separate work-items / 
fine things we do if we get everything else working properly.

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Mon, Apr 29, 2013 at 6:03 PM, Tommaso Cucinotta  wrote:
> On 29/04/13 23:32, Nico Williams wrote:
>>> However, when considering that other users might be editing stuff 
>>> above/before our
>>> cursor position, then it means this way of referencing positions within the 
>>> text
>>> should be changed/reworked to a pointer-based one.
>>
>> But what alternative addressing schemes could there be?
>
> well, when I wrote pointer, I actually meant C/C++ pointer :-). It's fixed,
> it doesn't change, it simply refs the paragraph, regardless of what other
> paragraphs precede it, or whether it is moved around (ParagraphList is a
> list, isn't it ?)

Well...  If a paragraph is deleted then the pointer might get assigned
in a subsequent allocation and... you end up with an aliasing problem.

I strongly recommend instead that you have a "paragraph ID" (call it
pointer if you like), saved in .lyx (this is important), and
consisting of two things:

 - a local LyX/host/whatever instance ID (can be re-generated every
time LyX starts)

 - a paragraph ID that is assigned (and saved in the .lyx!) when the
paragraph is created (if an old .lyx doesn't have this... then assign
one at open / conversion time).

> Now, the problem comes when deleting a paragraph: we need to check that no
> other cursors are on it, otherwise either forbid the operation or move the
> other cursors at the end of the removed part.

You can't do that.  Assume chat servers/peers come and go.  You don't
want to wait potentially forever, and you don't want to implement a
distributed locking protocol (for the same reason).  Nor do you want
to worry about split-brains (netsplits).

> Further issue is characters, as there's no list of characters in LyX, AFAICR,
> but it's a contiguous array. So, for chars there seems to be no other way
> than keeping a pos index..., or reworking that as a CharacterList.{h,cpp},
> which I'm quite sure somebody wouldn't like.

Version everything and assign version numbers; keep history.
Alternatively use hash-of-paragraph-contents as version numbers; keep
history.

> Given also issues raised in that a newcomer should not be messing around the
> core of LyX and refactor the cursor, because of the risk of entering a
> stability nightmare, it may be valuable to consider to keep the cursor as
> it is, and instead add the necessary logic to modify affected cursors of
> other concurrent editors consistently with the action.
>
> For example:
> -) when inserting a new character (LFUN_SELF_INSERT):
>for each cursor in same par in positions beyond this, do a pos++
> -) when inserting a new par (on Enter):
>for each cursor in later pars, do a pit++
> -) others for cut'n'paste, etc...
> -) I know, cases will grow fast...

See above.  You can't really synchronize this way.

Instead you want to have each LyX instance see something like a stream
of events, some locally-generated, some not.  You can get out of sync
with such a scheme, but i think you can arrange (by keeping enough
history) to resolve conflicts deterministically to end up with the
same content.  However, if two or more LyX instances continue to edit
for long enough through a netsplit then you may have to have the users
merge conflicting paragraphs.

>> I'm thinking
>> of a hash-based scheme, something like {{hash of paragraph contents},
>> offset into paragraph.
>
> while extremely git-ish :-), it would have the problem of identical paragraphs
> that are very possible in documents (e.g., right after a copy'n'paste).

Assigning a globally-unique paragraph ID on paragraph create is safer.
 But LyX could easily allow a paragraph to have copies in multiple
places in the same doc either way, but it's all much easier with
globally-unique paragraph IDs.

Nico
--

Re: GSoC 2013: Interactive LyX

[Nico Williams]

On Mon, Apr 29, 2013 at 6:21 PM, Tommaso Cucinotta  wrote:
> On 30/04/13 00:11, Nico Williams wrote:
>> But do you want to reuse an OTR
>> implementation?
>
> The question is why OTR, but perhaps the answer is simply that is already 
> made to be compatible with messaging protocols.

OTR is the only open protocol that exists today for end-to-end
authenticated encryption over IM.  There's also Apple's iMessage, but
that's proprietary.  Neither XMPP, nor AIM, nor IRC, ... provide the
same feature.  Hmmm, I may tell a lie: there's also SILC, but I know
little about it and it's very niche.

Merely using XMPP with TLS does not provide end-to-end security.

Mind you, even with OTR, most users never bother authenticating each
other, I think, and so they end up with potential men-in-the-middle
(MITMs).  But at least they can authenticate (and detect the MITMs),
and if they don't they still get protection from passive
eavesdroppers, no matter what the XMPP fabric does in the middle.

> However, security may be one of the optional add-on / separate work-items / 
> fine things we do if we get everything else working properly.

Right, but if you use a library that already has OTR then you're good
to go.  Well, that's another lie: you still need to provide a UI for
OTR, but that goes with using XMPP (or whatever) in the first place
too.

Nico
--

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 30/04/13 00:03, Tommaso Cucinotta wrote:
> For example:
> -) when inserting a new character (LFUN_SELF_INSERT):
>for each cursor in same par in positions beyond this, do a pos++
> -) when inserting a new par (on Enter):
>for each cursor in later pars, do a pit++
> -) others for cut'n'paste, etc...
> -) I know, cases will grow fast...

-) when adding a column and/or row, do a _idx += whatever-needed,
   to achieve the equivalent ++row() or ++col() ?

-) handle correspondingly the delete cases and decrement as needed.

T.

Re: GSoC 2013: Interactive LyX

[Nico Williams]

BTW, this has all been solved before (clearly).  Research it and use
whatever protocol pattern is most appropriate (or, if you can't
because of patents, invent a new protocol).

Some posts on this list pointed at some such prior work.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 20/04/13 21:25, Pavel Sanda wrote:
 As proposed by someone else it might have even more sense to think
 about chat project as pidgin/... add-on than lyx feature.

Yes, we might think of packing the LyX editor feature so that you can reuse 
it plugging it into another software, and actually I had proposed this also as 
one of possible projects, smth along the line of a LyX Qt Widget. However, 
I'm also realistic and I'm not sure that's really feasible. Or, we can think of 
pulling reusable features from existing chat clients, but Pidgin is 
Gtk-oriented, Kopete is Qt/Kde, but in the end it may be sufficient to just use 
a XMPP library within LyX.

Now, a LyX panel showing a list of users by enumerating them through some 
library call and handling the session state, does not seem to be such a big 
code base to pull into LyX, am I wrong ?

 Exactly. When I asked about XMPP I didn't mean we should actually use jabber
 server for exchanging real data,

I'm actually thinking of using exactly one of these XMPP servers. If we 
exchange text, then LyX would behave as any another client, and users could 
find each other on some of these servers, which have already in place all the 
infrastructure for registering users etc... (e.g., jabber.org). However, as the 
protocol seems extensible, perhaps one can exchange even binary stuff (e.g., it 
seems to support binary file exchange with some extension) or use it just to 
set-up a user-to-user connection and use it as we like.

 but to just let find two users bypass nat/firewalls 
 in order to exchange real connection points and let them directly connect via
 nat traversal techniques.

in the end, either one of the two is visible from the other, or we need a 
server, don't we ? Ok, we can use some DynDNS magic in case of non-static IPs, 
and manually reconfigure home modems/routers to redirect a LyX port, but that 
means being a pain to use the feature.

 This all be wrapped in some net machinery, from core we should just see
 dat comming/out from some pipe/socket/whatever.

agree.

 Frankly, if working on this project, I would just start with simple ip-ip to
 see what perfromance at best can we get and what sort of troubles appear
 _inside_ lyx (we need two/more cursors, I have little idea what we need to do
 to extend inner machinery and certainly it can be very tough to understand for
 newcomer all the cursor stuff we currently have!).
 
 Only then it makes sense to start pondering over the implementation how the
 actual net exchange would be done.

well, that was the purpose of my 1st hack. For the chat, now it's time to check
how the network part can be properly done, avoiding as much as possible to build
yet another server and yet another protocol and yet another users registration
facility etc
For the interactive lyx, the quick'n'dirty network part was already in my 1st 
hack,
and it was enough to realize there's a lot to be understood about how to deal 
with
lyx internals, as you say, multiple Cursors, or as said in some other thread, if
we should switch from index-based to ptr-based CursorSlice, etc...
Still, discussion about how to do best the network part is useful and needed, if
this thing must be usable by non-experts, one day (see also comment above).

 Second thought: if we have interactive lyx done, what is the need for lyx-chat
 project at all? Simply split windows inside edit window and you are done.

Not really like chatting (talk/talkd vs pidgin), but you raise a good point.
At the end, we're supposed to get a few student slots from G!, and
we'll likely have a higher number of projects. Then, we'll need to put some
priority on the projects, and see which ones seem more useful, urgent/needed,
and also *feasible* or likely to achieve a good usability status at the end,
also considering the applicant students.

As of now, I can see a straightforward path for the chat, whilst the interactive
lyx seems more challenging, it risks to touch core internals of lyx, or it
constitutes an opportunity to fix a number of things therein, and it risks to
encounter serious obstacles along the path (conflicts management, temporary
off-line editors ?...)

Any comment welcome. Thanks, bye.

T.

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Tommaso Cucinotta wrote:
 Now, a LyX panel showing a list of users by enumerating them through some 
 library call and handling the session state, does not seem to be such a big 
 code base to pull into LyX, am I wrong ?

Panel showing list of strings is not problem, I'm concerned about the 
networking/user management part.
 
  Exactly. When I asked about XMPP I didn't mean we should actually use jabber
  server for exchanging real data,
 
 I'm actually thinking of using exactly one of these XMPP servers. 

My guess is that the time delay would be such that you would need to implement
some of the transaction protocols pointed previously so what you have saved on
net trickery would more than compensated by the complexity of merging problems
you have to solve. Maybe the only way how to know is to try rudimentary form
of both of them and see.

  but to just let find two users bypass nat/firewalls in order to exchange
  real connection points and let them directly connect via nat traversal
  techniques.
 
 in the end, either one of the two is visible from the other, or we need a
 server, don't we ?

Well, yes and no. What I meant is to use server just for helping with
establishing the connection when both users are behind nat, rest would be
direct peer-to-peer.

 lyx internals, as you say, multiple Cursors, or as said in some other thread, 
 if
 we should switch from index-based to ptr-based CursorSlice, etc...

I'm pessimist that newcomer in the project should start substantial cursorslice
refactoring. There are so many corners to know about and anyone responsible
for deeper changes should be around for longer time than just one summer.

  Second thought: if we have interactive lyx done, what is the need for 
  lyx-chat
  project at all? Simply split windows inside edit window and you are done.
 
 Not really like chatting (talk/talkd vs pidgin),

I see, you are right.

 As of now, I can see a straightforward path for the chat, whilst the 
 interactive
 lyx seems more challenging, it risks to touch core internals of lyx, or it
 constitutes an opportunity to fix a number of things therein, and it risks to
 encounter serious obstacles along the path (conflicts management, temporary
 off-line editors ?...)

OTOH interactive LyX seems to be really worth and requested feature while the
chat looks more like a toy with the aroma of the word bloat around (sorry for
the punch :) 
Also consider the wider perspective that it's better to attract devs willing to
become experts in lyx internals than devs who are willing to become experts
in 3rd party technologies like jabber. The probability of second group staying
around lyx devel is IMHO much lower.

Pavel

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 20/04/13 21:25, Pavel Sanda wrote:
> As proposed by someone else it might have even more sense to think
> about chat project as pidgin/... add-on than lyx feature.

Yes, we might think of "packing" the LyX editor feature so that you can reuse 
it plugging it into another software, and actually I had proposed this also as 
one of possible projects, smth along the line of a "LyX Qt Widget". However, 
I'm also realistic and I'm not sure that's really feasible. Or, we can think of 
pulling reusable features from existing chat clients, but Pidgin is 
Gtk-oriented, Kopete is Qt/Kde, but in the end it may be sufficient to just use 
a XMPP library within LyX.

Now, a LyX panel showing a list of users by enumerating them through some 
library call and handling the session state, does not seem to be such a big 
code base to pull into LyX, am I wrong ?

> Exactly. When I asked about XMPP I didn't mean we should actually use jabber
> server for exchanging real data,

I'm actually thinking of using exactly one of these XMPP servers. If we 
exchange text, then LyX would behave as any another client, and users could 
find each other on some of these servers, which have already in place all the 
infrastructure for registering users etc... (e.g., jabber.org). However, as the 
protocol seems extensible, perhaps one can exchange even binary stuff (e.g., it 
seems to support binary file exchange with some extension) or use it just to 
set-up a user-to-user connection and use it as we like.

> but to just let find two users bypass nat/firewalls 
> in order to exchange real connection points and let them directly connect via
> nat traversal techniques.

in the end, either one of the two is visible from the other, or we need a 
server, don't we ? Ok, we can use some DynDNS magic in case of non-static IPs, 
and manually reconfigure home modems/routers to redirect a "LyX port", but that 
means being a pain to use the feature.

> This all be wrapped in some net machinery, from core we should just see
> dat comming/out from some pipe/socket/whatever.

agree.

> Frankly, if working on this project, I would just start with simple ip<->ip to
> see what perfromance at best can we get and what sort of troubles appear
> _inside_ lyx (we need two/more cursors, I have little idea what we need to do
> to extend inner machinery and certainly it can be very tough to understand for
> newcomer all the cursor stuff we currently have!).
> 
> Only then it makes sense to start pondering over the implementation how the
> actual net exchange would be done.

well, that was the purpose of my 1st hack. For the chat, now it's time to check
how the network part can be properly done, avoiding as much as possible to build
yet another server and yet another protocol and yet another users registration
facility etc
For the interactive lyx, the quick'n'dirty network part was already in my 1st 
hack,
and it was enough to realize there's a lot to be understood about how to deal 
with
lyx internals, as you say, multiple Cursors, or as said in some other thread, if
we should switch from index-based to ptr-based CursorSlice, etc...
Still, discussion about how to do best the network part is useful and needed, if
this thing must be usable by non-experts, one day (see also comment above).

> Second thought: if we have interactive lyx done, what is the need for lyx-chat
> project at all? Simply split windows inside edit window and you are done.

Not really like chatting (talk/talkd vs pidgin), but you raise a good point.
At the end, we're supposed to get a few student slots from G!, and
we'll likely have a higher number of projects. Then, we'll need to put some
priority on the projects, and see which ones seem more useful, urgent/needed,
and also *feasible* or likely to achieve a good usability status at the end,
also considering the applicant students.

As of now, I can see a straightforward path for the chat, whilst the interactive
lyx seems more challenging, it risks to touch core internals of lyx, or it
constitutes an opportunity to fix a number of things therein, and it risks to
encounter serious obstacles along the path (conflicts management, temporary
off-line editors ?...)

Any comment welcome. Thanks, bye.

T.

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Tommaso Cucinotta wrote:
> Now, a LyX panel showing a list of users by enumerating them through some 
> library call and handling the session state, does not seem to be such a big 
> code base to pull into LyX, am I wrong ?

Panel showing list of strings is not problem, I'm concerned about the 
networking/user management part.
 
> > Exactly. When I asked about XMPP I didn't mean we should actually use jabber
> > server for exchanging real data,
> 
> I'm actually thinking of using exactly one of these XMPP servers. 

My guess is that the time delay would be such that you would need to implement
some of the transaction protocols pointed previously so what you have saved on
net trickery would more than compensated by the complexity of merging problems
you have to solve. Maybe the only way how to know is to try rudimentary form
of both of them and see.

> > but to just let find two users bypass nat/firewalls in order to exchange
> > real connection points and let them directly connect via nat traversal
> > techniques.
> 
> in the end, either one of the two is visible from the other, or we need a
> server, don't we ?

Well, yes and no. What I meant is to use server just for helping with
establishing the connection when both users are behind nat, rest would be
direct peer-to-peer.

> lyx internals, as you say, multiple Cursors, or as said in some other thread, 
> if
> we should switch from index-based to ptr-based CursorSlice, etc...

I'm pessimist that newcomer in the project should start substantial cursorslice
refactoring. There are so many corners to know about and anyone responsible
for deeper changes should be around for longer time than just one summer.

> > Second thought: if we have interactive lyx done, what is the need for 
> > lyx-chat
> > project at all? Simply split windows inside edit window and you are done.
> 
> Not really like chatting (talk/talkd vs pidgin),

I see, you are right.

> As of now, I can see a straightforward path for the chat, whilst the 
> interactive
> lyx seems more challenging, it risks to touch core internals of lyx, or it
> constitutes an opportunity to fix a number of things therein, and it risks to
> encounter serious obstacles along the path (conflicts management, temporary
> off-line editors ?...)

OTOH interactive LyX seems to be really worth and requested feature while the
chat looks more like a toy with the aroma of the word "bloat" around (sorry for
the punch :) 
Also consider the wider perspective that it's better to attract devs willing to
become experts in lyx internals than devs who are willing to become experts
in 3rd party technologies like jabber. The probability of second group staying
around lyx devel is IMHO much lower.

Pavel

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 20/04/13 00:54, Marcelo Galvão Póvoa wrote:
 I checked and and it seems libpurple can handle multiple IM protocols
 at once, but using it directly would require creating new interfaces
 inside LyX for authentication, contacts list, etc. 

I just found a few pointers of attempts to build a Qt GUI for libpurple

  http://pidgin.im/pipermail/devel/2008-November/007079.html

but I have no clue of whether there might be any reusable code there.
Also, it seems Pidgin and libpurple are heavily intertwined with GLib/Gtk.

Perhaps we should have a look at multi-protocol KDE-based IM clients,
e.g., Kopete ?

  http://www.linuxlinks.com/article/20070724175038927/Kopete.html

Any heavy KDE user on the list who can advise on what is a good one ?

 So, as I said
 earlier, since the project already seems quite large as is, it would
 be better to discuss a list of deliverables for the GSoC and how they
 should be implemented.

As for intermediate checkpoints within the project, for the chat:
1) minimal GUI panel within LyX for login and friends selection within
   some of these IM systems (things like searching for and adding friends
   may be handled through an external client -- in LyX we just need to
   see who is online and start chatting)
2) chat functionality; it might be interesting to investigate on keeping
   compatibility with text-only clients, i.e., one chats in LyX the other
   sees and writes LaTeX :-)
3) client-side encryption add-on: can we exchange b64 encoding of client-side
   encrypted text segments, so that IM servers cannot see what's being 
exchanged ?

As for the more challenging interactive lyx project, I'm not sure any of these
pre-existing IM infrastructures are appropriate, the key issue being how long
a message takes to be delivered to the destination. For IM chats, I wouldn't
expect a server to hurry up in delivering msgs. But it also depends on what
functionality and extensibility options are there in these extensible protocols.

T.

Re: GSoC 2013: Interactive LyX

[Tommaso Cucinotta]

On 20/04/13 10:19, Tommaso Cucinotta wrote:
 As for the more challenging interactive lyx project, I'm not sure any of these
 pre-existing IM infrastructures are appropriate, the key issue being how long
 a message takes to be delivered to the destination. For IM chats, I wouldn't
 expect a server to hurry up in delivering msgs. But it also depends on what
 functionality and extensibility options are there in these extensible 
 protocols.

Perhaps a look into jingle is needed

  https://developers.google.com/talk/libjingle/

Concerning the interactive editing, I also remembered some critical issues faced
during my prior quick hack: LyX internally uses index positions for the cursor,
i.e., my cursor is on the 3rd paragraph, 5th character, and in case of insets it
goes recursively down the hierarchy.

However, when considering that other users might be editing stuff above/before 
our
cursor position, then it means this way of referencing positions within the text
should be changed/reworked to a pointer-based one.

So, considering your desired intermediate steps list, a zero step is some rework
of LyX internals such as this (affecting Cursor, CursorSlice etc...). This is 
also
all useful to get familiar with this cursor positioning part of the code, that 
is
also important to understand whether 2 users may be editing conflicting parts, 
and
to understand the best way to handle conflicts in LyX.

T.

Re: GSoC 2013: Interactive LyX

[Vinícius dos Santos Oliveira]

2013/4/20 Tommaso Cucinotta tomm...@lyx.org

 3) client-side encryption add-on: can we exchange b64 encoding of
 client-side
encrypted text segments, so that IM servers cannot see what's being
 exchanged ?


It's possible to use OTR:
http://en.wikipedia.org/wiki/Off-the-Record_Messaging


-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker

Re: GSoC 2013: Interactive LyX and Google Docs

[Gregori Kanatzidis]

The API isn't open at this point, there's a simple integration that we made
available that you can see here:

https://spandex.io/api/simple-site-integration-post
https://spandex.io/api/simple-site-integration-get

But it's not sufficient for this use. We're still designing the API and are
hoping to be able to start opening up more relevant parts of it in a couple
of weeks. We'd be happy to hear your thoughts if you have suggestions as
well.

Best,
Gregori


On Fri, Apr 19, 2013 at 7:43 PM, Vinícius dos Santos Oliveira 
vini.ipsma...@gmail.com wrote:

 2013/4/19 Gregori Kanatzidis kanatzid...@gmail.com

 I've posted in another thread about this, but my company 
 SpanDeXhttp://spandex.io is
 opening up its API and all the OT stuff is already implemented and hosted.
 If you're interested we could work with you to figure out how best to go
 about it.


 It sounds interesting.

 Is the API already open? Could you point us to the documentation?
 =)



 --
 Vinícius dos Santos Oliveira
 https://about.me/vinipsmaker




-- 
-
*Gregori Kanatzidis*
B.S. Candidate, Electrical Engineering
http://kanatzidis.com
TEL: 5178626464

Re: GSoC 2013: Interactive LyX and Google Docs

[Vinícius dos Santos Oliveira]

2013/4/20 Gregori Kanatzidis kanatzid...@gmail.com

 We're still designing the API and are hoping to be able to start opening
 up more relevant parts of it in a couple of weeks.


I don't know if it will be fast enough. Student application proposals ends
in may 3.

But it's excellent news anyway.
=)

We'd be happy to hear your thoughts if you have suggestions as well.


I'll try to come up with something later today.


-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker

Re: GSoC 2013: Interactive LyX

[Pavel Sanda]

Tommaso Cucinotta wrote:
   (things like searching for and adding friends
may be handled through an external client

Yep, we need to outsource this business out of lyx as much as possible because
of the maintenance pain.
As proposed by someone else it might have even more sense to think
about chat project as pidgin/... add-on than lyx feature.

 pre-existing IM infrastructures are appropriate, the key issue being how long
 a message takes to be delivered to the destination. For IM chats, I wouldn't

Exactly. When I asked about XMPP I didn't mean we should actually use jabber
server for exchanging real data, but to just let find two users bypass 
nat/firewalls 
in order to exchange real connection points and let them directly connect via
nat traversal techniques.

This all be wrapped in some net machinery, from core we should just see
dat comming/out from some pipe/socket/whatever. That's also why I think
that allowing direct ip-ip connection is not a problem; it's just a
switch between scenarios when we directly see and when we call extended
routines to bypass the initial connection via XMPP/whatever.

Frankly, if working on this project, I would just start with simple ip-ip to
see what perfromance at best can we get and what sort of troubles appear
_inside_ lyx (we need two/more cursors, I have little idea what we need to do
to extend inner machinery and certainly it can be very tough to understand for
newcomer all the cursor stuff we currently have!).

Only then it makes sense to start pondering over the implementation how the
actual net exchange would be done. We can even add later different scenarios
how the message passing is done so *the main point is to have clearly separated
net passing layer so core knows nothing about that.* I'm pretty sure that even
if you don't care about the direct connections, and use sophisticated solution
for letting users find each other, it would take me just few lines of code to
add this.

...

Second thought: if we have interactive lyx done, what is the need for lyx-chat
project at all? Simply split windows inside edit window and you are done.

Pavel