Re: [GSoC] Impress Remote Protocol

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.