On Tue, Jan 3, 2012 at 2:18 AM, Tommaso Cucinotta <tomm...@lyx.org> wrote:
> Il 02/01/2012 14:54, Abdelrazak Younes ha scritto: > >> First comment: please use QTcpSocket and signal/slot connections. >> > > Still pending, I'll convert to QTcpSocket soon. > > Please, find attached the 2nd draft/skeleton of this. Changes: > 1) a new BufferView is created for each new connection, all'em are added > to remote_views_ associated with a (local) BufferView > 2) a server receives messages from any of the remote_views_, then it > applies them and forwards them to all the remote_views_ except the one from > which it received > 3) a client simply receives messages and applies them locally > 4) both server and client echo the locally dispatched LFUNs to all the > remote_views_. > > In my previous patch, the client and remote bufferviews were only 2 and > they were copying the cursor movements of each other as well, so they were > actually only one single cursor etc. This time, instead, the remote users > have their separate bufferview and cursors, and they can operate > independently from one another. > This is good :-) > > Shortly, this should allow also more clients to connect to the same > BufferView (which will have bound previously through a A-x collaborate-bind > <port>), then each change made by anyone will be forwarded to all the > others. Things work in so far the changes don't overlap. How to detect > overlaps, and how to handle them, is the *dark part* of this feature IMO. > Also, nothing prevents a LyX instance to share remotely more than 1 buffer > with different clients. Just, each shared buffer needs to collaborate-bind > on a different port. > > If you want to try the patch, you need to launch 2 lyx instances, create a > new empty doc in both of them, then having one to collaborate-bind <port>, > the other to collaborate-connect <host> <port>, but beware that it will > soon crash close to some metrics-related or cursor-related assertion. Also, > if you really wanted to try with different hosts, then you'd better change > the bind() host/iface address in BufferView.cpp from "127.0.0.1" to > "0.0.0.0". > I'll try to review and test your patch tonight. > > I wanted to share a video, but xvidcap crashes deterministically, so I > can't :-(. > > Still a small connection-setup protocol is missing (easy task), in which > the server sends the whole buffer to which the client connected over the > network, so that the client will create a brand new WorkArea and work on it. > One general comment: IMO we should have a dedicated proxy server program for this stuff, i.e. remove all server related code from your patch and put that in a new daemon tool. This means that this tool could be launched anywhere on the internet and the LyX instances don't have to know their respective IP addresses, only the server one. I would call this new tool LPS that is LyX Proxy Server. No Gui in there, just a TCP server that will proxy the lyx commands between the connected LyX instances. We would need a small protocol to set client ids, to retrieve list of connected clients, etc. After that, maybe we could switch to a standard protocol as suggested by Rob. Cheers, Abdel.
