On 16/03/14 15:57, Sushant Raikar wrote:
> thats brilliant! :) , now I understood why you had multiple remote
> views! you were essentially keeping separate hidden buffer for each
> of the client.
(Almost) exactly, but it's NOT multiple hidden buffers, but rather multiple
hidden BufferView! See below.
> please clarify, client holds remote buffer of server(only one) ,
> server holds remote buffers of all the clients.
Not really buffers: so, let me try to clarify the LyX objects:
- Buffer, contains the pure document (no GUI, no cursor, no selection, nothing
related to how you edit it)
- BufferView, represents a view on the document, so it does contain the cursor,
as well as info
related to how you're viewing the document on screen; however, the full
GUI-level info is
contained within:
- WorkArea/GuiWorkArea, this has all stuff concerning Qt-specifics, on-screen
appearence, etc...
So, in my old patch (I hope I remember well, see the code to double-check):
- a BufferView in a LyX instance behaves as server, listening to a IP addr/port
(you do it through the mini-buffer, with Alt-x, listen args...)
- from another LyX instance, you can instantiate a client BufferView, that
connects
to the server addr/port (you do it through Alt-x, connect args...)
However, the server has a single Buffer object, but, in addition to its own
BufferView(s)
as due to the user locally editing the document, it has also a remote
BufferView for each
connected client, corresponding to the remote users' actions (e.g., each remote
BufferView
contains the position of a client cursor on the document).
Each client also has a local Buffer, and a remote BufferView acting as client
for the
server's document, and representing the server's cursor position.
First time a client connects to a server, its current document is replaced by
the one on
the server at that time, then editing goes further from that point.
So, any edit locally done by the user on the server, is also sent to all the
clients and
replayed again on the client local buffers through the local client BufferView.
Dually,
any edit done by client users is sent to the server remote BufferView, which in
turn
re-dispatches the edit to any further client.
However, note that the scheme was principally thought for 1-to-1, and I'm not
even sure
if there's any major flaw that prevents it from working in the case of more
than 1 client.
In the proposal related to this project, please, ensure you propose your own
way to deal
with more than 2 users collaborating, if you intend to support that, or make it
explicit
if you intend to start from 1-to-1, then expand the feature, etc...
T.
