[GSoC] Impress Remote Protocol

[Michael Meeks]

On Sat, 2013-06-15 at 19:14 +0300, Artur Dryomov wrote:
> Yep, I already read the code in the process of preparing the wiki
> page. I thought maybe something was wrong or not correct

	The protocol is deliberately simple; the problem space is also
reasonably simple - hopefully that makes a good match :-) a plain text
protocol is also hopefully readable and easy to debug. In addition -
while it is easy to update Android devices to the latest version - so
back-compat with old remote software is not a problem, the same is not
so true for the laptop end of the piece: 100Mb+ downloads plus (on
windows at least) horribly slow MSI processing to get a new version. So
- I'd like to keep the remote side compatible with old LibreOffice's if
possible.

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

	Right :-)

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

	I tend to agree.

> The compatibility will be broken anyway even if there will be just
> extended protocol. 

	Why ? It should be possible to accept being pushed slide thumbnails, as
well as being able to request specific slides' data as/when needed -
surely there is not a huge problem with that ?

> I have plans to cut off sending information about all slides on
> presentations start and it will break the current Android client

	Ideally we would assume that the android device can be easily updated,
but the C++ side much less so - and take care to continue working with
the old protocol - but of course, enable better modes of operation /
newer protocols if possible.

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

	Of course true; plain-text is not ideal with a highly complicated very
structured thing; on the other hand - we can easily add a:
"complicated_command" command (or somesuch) that takes an XML blob full
of impenetrable, hard to parse stuff ;-)

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

	I am -very- suspicious of the second-system problem. What we have
works, it has some problems - but it is also rather minimal. I would
really prefer not to replace it with something that is over-engineered -
the best way (usually) to avoid that is to focus on the user-experience
and new features to drive the low-level extensions we want; rather than
the reverse :-)

	That's my 2 cents anyhow,

	HTH,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot