Il 02/01/2012 18:05, Rob Oakes ha scritto:
To that end, I'd prefer any collaborative writing features to:
1.) Use an existing open source messaging protocol like Jabber (which
means that any XMPP server could be used for collaboration). Passing
information about geometry, actions, etc. seems like it would be pretty
straightforward.
I'd be happy to, and I also had a quick look at Pidgin plugins, as someone
on the list pointed out that the chat might have been realized as a Pidgin
plugin or smth. like that. The problem is that, AFAICU, if we had our own
LyX protocol and server, then we could write a Pidgin plugin that logs into
your account over there, and allows you to have LyX-enhanced collaborations.
However, I wasn't able to understand whether any already existing
chat-messaging systems
has a sufficiently generic protocol so that you can plug an arbitrarily
complex contents (such as LyX-enhanced contents) into it, e.g., via MIME
or similar.
Second, back to the collaborative feature, more or less the same issue. If
there's any reusable system out there that allows to register users, then
use a customized/extended protocol that allows us to exchange LFUNs
and/or LyX files and/or whatever we need over it, then I'd be fine with
that. However, I'm completely ignorant in such matters as those protocols,
tools, servers and on-line systems mentioned by you guys.
That was the only reason why I was proposing to write a small server,
as in principle the functionality is small and the users base is expected
to not be huge at all. However, having an automatic on-line management
of users accounts, in which normally you want to handle e-mail based ack
of e-mail addresses, and also secure SSL/TLS sessions with the LyX
instances,
and who knows what else, I understand the features grow up very quickly...
But, first of all, what is important is how the feature might behave on the
LyX side (server-side is nearly unimportant from this viewpoint -- except
how you authenticate, connect and start the sessions).
T.
2.) Reuse external tools and libraries as much as possible (e.g.
libpurple), limiting the LyX-specific code we would need to develop and
maintain.
3.) Remain as open as possible, meaning that we don't tie users to a
specific service. Using a generic solution, like Jabber would be ideal.
(Though running a server through LyX.org might be a good way to raise
funds for LyX development.)
Cheers,
Rob
