Hi,
On 13/06/13 19:32, Artur Dryomov wrote:
> Hi All,
>
> I have created a wiki page where I moved some information from Git and
> placed some thoughts about the Impress remote protocol.
>
> https://wiki.documentfoundation.org/Impress_Remote_Protocol
>
> It would be really great if Andrzej could improve the information
> about the first version of protocol.
> Probably there are other commands --- like pairing ones --- that are
> missed. But I can be wrong :-)
Looks correct, although I've not looked at this in a while so I might be
forgetting some details. The definitive resources however are
sd/source/ui/remotecontrol/Receiver.cxx &
android/sdremote/src/org/libreoffice/impressremote/communication/Receiver.java
which are both fairly small/simple.
>
> This page contains my proposal of the second version of protocol as well.
> It would be interesting to see other proposals and hear thoughts and
> opinions.
We actually did originally use JSON last year, but moved to a text based
protocol to avoid having to deal with additional libraries and to reduce
overhead, (although I'm not very well qualified to judge the relative
merits of each). The main issue is making sure that the protocol is
usable on all the necessary platforms. No idea how easy it is to use
JSON or XML with iOS, Android seems to have good support for JSON but no
idea about XML, Firefox OS (javascript) has great JSON support and
shouldn't be too hard to use XML either -- in any case plaintext is
still the easiest to parse. (I can't remember what library I used within
LO for json anymore -- it might have been json-glib -- but any
additional libraries mean extra work with integrating them into the LO
since I was using an external library.)
I don't see any real need to switch from plain text though -- the
commands are very simple (as most 3 parameters per command), i.e. easier
to parse directly than through another layer. Extending the current
protocol avoids having to do any special work to keep backwards
compatibility (e.g. any unrecognised commands will simply be ignored by
older clients at the moment). Adding another layer looks like it'll just
make the code more complicated without any benefit. It's even been
suggested to go the other way and use a binary protocol (although that
won't play well with the Firefox OS remote since Javascript doesn't like
binary).
A versioning/handshake system would still be useful though so that
clients and servers know what features are supported, especially w.r.t.
to knowing whether the laser pointer can be used / slide previews &
notes have to be actively fetched / etc.
> I'll read Google Play reviews soon to find out new feature requests.
> BTW --- is it possible to get the access to the Android developer console?
> Google Play shows reviews for a current language only, the developer
> console can show all reviews at once.
No idea -- I'm not entirely certain who controls the TDF Play account.
I think the two main ideas being floated though were adding a
"laser-pointer" and storage of presentations on the phone (i.e. as a
usb-stick/web/etc. replacement).
Also one thing I did look at but didn't get very far with was sending
fully formatted presentation notes -- at the moment they are unformatted
(except for newlines) -- the necessary logic to output html notes is
already in the export filters but would need adapting to output the
notes for a single slide.
ATB,
Andrzej
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
