On 14/04/13 05:45, Marcelo Galvão Póvoa wrote: > Greetings! > > My name is Marcelo Galvão Póvoa, a Computer Science graduate student from > UNICAMP, Brazil.
Hi Marcelo, welcome to LyX! As outlined by others, consider that to apply to GSoC 2013 for a project related to LyX you should follow the application procedure outlined here: http://www.google-melange.com/gsoc/org/google/gsoc2013/lyx. Of course we can preliminarily discuss on the list a number of issues related to the project, to understand what are the best implementation paths. See below. > Coincidentally enough, I have already coded such thing for a school project > once: it was a very simple text editor with support for multiple users > editing the same document with a server used to receive and dispatch updates. > It was written in Java using RMI and it behaved much like Google Docs does. > Indeed, it was very important to carefully design the update routines to > ensure consistency and be coherent. The most challenging part was dealing > with Undo/Redo operations after the contents were modified. Your prior experience seems valuable in this context, and I see you dropped a number of very focused questions arising sensible issues. > I have a couple questions to ask: > - Can someone point me to the proof-of-concept patch that was posted on the > list? I searched but couldn't find it. Both the LyX Chat and the collaborative editing were merged into a patch available at: http://www.lyx.org/trac/ticket/7964 > - Is the network approach supposed to be peer-to-peer? That patch was a quick'n'dirty hack that I realized in the fastest possible way. So, I assumed LyX instances could be reachable from one another, so I used one of them as a server, the other as a client. Unfortunately, this would not be the case 99% of the regular usage cases, so a server should be needed to let users find each other, from a networking perspective. However, also having the document kept onto a server may also be possible, but it has pros and cons: pros: - document always available, no need for waiting the server user to be on-line (as it was required in the patch). However, other possibilities are to allow for off-line editing, and synchronizing only when the users are on-line cons: - security/confidentiality: the server sees the document :-(! In the other case, info among users may be client-side encrypted, so the doc may be confidential to the users having access to it. Not sure if a server might limit itself to keep merely a set of encrypted actions to be propagated across clients, then when they connect they would get them and apply them locally to the document. In such a way, the security issue would be overcome, but perhaps consistency issues would become more difficult. Also, such a set-up might have lots in common between interactive editing and a chat client (suggested as two projects, merely because in the case of the chat there's no consistency issues to deal with, so it's easier). > If so, I guess it would be harder to ensure consistency across local copies > of the document since a user can disconnect at any time (e.g, just before or > after making an edit). A centralized approach would be easier, with the > server keeping a copy of the document, but should have more scalability > issues. all good remarks. > - How would we deal with more complex actions such as when a user adds an > image? If we just add the inset to the other user, the image reference will > be obviously broken, but should we actually upload the file? Doesn't seem > like a good idea since it may be modified later. in the protocol one might vehicle also the added external content(s), perhaps with as an optional action. Though, such a feature would "cross" with version-control features (support for git/svn...) > I am looking forward to your feedback. Just tried, thanks for your inquiry. Feel free to reply with your further comments. Thanks, T.
