On 20/04/13 21:25, Pavel Sanda wrote:
> As proposed by someone else it might have even more sense to think
> about chat project as pidgin/... add-on than lyx feature.
Yes, we might think of "packing" the LyX editor feature so that you can reuse
it plugging it into another software, and actually I had proposed this also as
one of possible projects, smth along the line of a "LyX Qt Widget". However,
I'm also realistic and I'm not sure that's really feasible. Or, we can think of
pulling reusable features from existing chat clients, but Pidgin is
Gtk-oriented, Kopete is Qt/Kde, but in the end it may be sufficient to just use
a XMPP library within LyX.
Now, a LyX panel showing a list of users by enumerating them through some
library call and handling the session state, does not seem to be such a big
code base to pull into LyX, am I wrong ?
> Exactly. When I asked about XMPP I didn't mean we should actually use jabber
> server for exchanging real data,
I'm actually thinking of using exactly one of these XMPP servers. If we
exchange text, then LyX would behave as any another client, and users could
find each other on some of these servers, which have already in place all the
infrastructure for registering users etc... (e.g., jabber.org). However, as the
protocol seems extensible, perhaps one can exchange even binary stuff (e.g., it
seems to support binary file exchange with some extension) or use it just to
set-up a user-to-user connection and use it as we like.
> but to just let find two users bypass nat/firewalls
> in order to exchange real connection points and let them directly connect via
> nat traversal techniques.
in the end, either one of the two is visible from the other, or we need a
server, don't we ? Ok, we can use some DynDNS magic in case of non-static IPs,
and manually reconfigure home modems/routers to redirect a "LyX port", but that
means being a pain to use the feature.
> This all be wrapped in some net machinery, from core we should just see
> dat comming/out from some pipe/socket/whatever.
agree.
> Frankly, if working on this project, I would just start with simple ip<->ip to
> see what perfromance at best can we get and what sort of troubles appear
> _inside_ lyx (we need two/more cursors, I have little idea what we need to do
> to extend inner machinery and certainly it can be very tough to understand for
> newcomer all the cursor stuff we currently have!).
>
> Only then it makes sense to start pondering over the implementation how the
> actual net exchange would be done.
well, that was the purpose of my 1st hack. For the chat, now it's time to check
how the network part can be properly done, avoiding as much as possible to build
yet another server and yet another protocol and yet another users registration
facility etc....
For the interactive lyx, the quick'n'dirty network part was already in my 1st
hack,
and it was enough to realize there's a lot to be understood about how to deal
with
lyx internals, as you say, multiple Cursors, or as said in some other thread, if
we should switch from index-based to ptr-based CursorSlice, etc...
Still, discussion about how to do best the network part is useful and needed, if
this thing must be usable by non-experts, one day (see also comment above).
> Second thought: if we have interactive lyx done, what is the need for lyx-chat
> project at all? Simply split windows inside edit window and you are done.
Not really like chatting (talk/talkd vs pidgin), but you raise a good point.
At the end, we're supposed to get a few student slots from G!, and
we'll likely have a higher number of projects. Then, we'll need to put some
priority on the projects, and see which ones seem more useful, urgent/needed,
and also *feasible* or likely to achieve a good usability status at the end,
also considering the applicant students.
As of now, I can see a straightforward path for the chat, whilst the interactive
lyx seems more challenging, it risks to touch core internals of lyx, or it
constitutes an opportunity to fix a number of things therein, and it risks to
encounter serious obstacles along the path (conflicts management, temporary
off-line editors ?...)
Any comment welcome. Thanks, bye.
T.
