Hi,
yes, you got right what the initial focus would be for interactive lyx, and if
you
like/love the idea of seeing that feature up and running, then it's definitely
the
one you should focus on.
A few further notes:
-) the simple use-case you can see in that old video of mine is really a bad
hack
and the software with that patch crashes after a few keystrokes; even the
simple
use-case of 2 users editing the same doc needs a nice design/engineering
effort
to be handled in a robust, safe and meaningful way (more on this later)
-) in my opinion, the starting point is NOT a Qt GUI mock-up; the GUI is already
there, and it is essentially LyX itself; ok, we might have a few further GUI
elements, like showing where other users' cursors are editing, or perhaps
showing paragraphs that are being modified by others and we'd not be supposed
to touch, or perhaps some interactive panel for sorting out conflicts
-) the key point in this project is to propose an algorithm for merging multiple
edits coming asynchronously from different views (local and remote) on the
same document, and handling the various possible conflict cases (imagine I am
editing a paragraph but another user is cutting and pasting it somewhere
else,
or I'm changing a word in a way, but another user tries to do the same, or
to change it to something different, etc.); AND, to propose an implementation
plan that allows for the basic skeleton/structure to be up and running, and
upon which we may build further the feature in the future...
-) for example, you can find some discussion we had for last year GSoC on the
mailing list archives, searching for GSoC 2013: Interactive LyX, e.g., see
the full thread starting at:
https://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg178180.html
and other similar discussions...
-) in other words, I think the focus is most on the side of what exact messages
we exchange over the network (users commands, revisions of document,
revisions
of paragraphs, ID of paragraphs and/or of the nested inset hierarchy where
we're
editing, etc...), and how we use that information fruitfully on the
receiver(s)
side to converge to a common/consistent view of what's being edited;
possibly, considering what LyX internals might need changes to enable that,
if needed
And, you're right about uniqueness -- similarly to Advanced Find & Replace, I
was
fascinated by the idea to propose and realize something quite unique that other
editors don't seem to have... this gives me a lot of motivation & fun :-)!
T.
On 09/03/14 04:53, Sushant Raikar wrote:
> Tommaso,
>
>
>>My advice would be: in the GSoC'14 project time span, we pick any
>>transport protocol at random that allows us to start, trying to keep the
>>code sufficiently independent, so that it can possibly be changed later.
>>Considering the available time, there are already sufficient challenges
>>in terms of how to handle the merging of multiple edits by the various
>>users in real-time, and that's where the focus has to be.
>
> So the primary focus of the project is the collaborative interaction of 2 or
> more end users.
> Handling cases like simultaneous updation , undo /redo ,
> locking/unlocking(suppose
> user_1 doesnt want user_2 to make changes in some text).
> Simple use case like independent synchronous (one after the other) updation
> http://retis.sssup.it/~tommaso/lyx-collaborate.ogv has already been
> implemented.
>
>
> I am going to start working on my proposal,
> this is the time-line (in brief)
> *get familiar with lyx internals
> *decide on a end to end communication method (preferably QSocket..)
> *handle use cases (keep code independent as much as possible)
> *on sufficient reliable success (make code dependent and integrate with Lyx)
>
> I am currently thinking about the possible use cases and how to tackle them..
> and I am going through the patch code.
> I am a little unclear of what the milestones will be,could you point me to
> some articles
> which I might find related?.
>
> Also should I start off with a mock up of simple text editor in Qt with
> collaborative properties?
>
> -------------------------------------------------------------------------------------------------------------------------
>>The only answer I can feel like giving you is: pick the one that you like
>>most, that intrigues you most, that seems most useful for you, that seems
>>easier for you to accomplish, or that seems harder and more challenging
>>for you, depending on your personal orientation :-).
>
> I think it would be better if I work on Interactive LyX, considering I am more
> experienced in sockets rather than RegExps . And it will be more fun and
> challenging to
> work on possible use cases. And also most importantly its influence on users
> , as this feature
> is unique to Lyx (isn't it?).
>
