[GSoC] Impress Remote Protocol

[Artur Dryomov]

Hi Andrzej,

> 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.

Yep, I already read the code in the process of preparing the wiki page. I thought maybe something was wrong or not correct and you can fix it.

> 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 agree about JSON, an extra dependency is not a nice solution so I promoted XML as well.

> 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).

The compatibility will be broken anyway even if there will be just extended protocol. I have plans to cut off sending information about all slides on presentations start and it will break the current Android client because it relies exactly on such behavior.

I cannot agree that plain text is the best solution as well. JSON or XML will allow us to use not positional arguments but named ones so instead of parsing, for example, second argument we could use a “coordinates” property and so on. Such high-level interface will allow client implementations to map structures directly to objects. It is scalable as well — it is easy to add a property to output when it has name, the current protocol relies on positions as parameters identifiers so when there will be, for example, ten parameters it will be hard to manage what position has parameter you actually need.

I can be too radical actually and it would be interesting to hear other opinions. That’s why I posted this message to the mailing list :-)

> 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.

Hmm, notes look like HTML documents, don’t they have any formatting? :-? I haven’t try it yet.

Regards,
Artur.