[GSoC] Impress Remote Protocol

[Siqi Liu]

Hello all,

First, it's great to have a wiki page here, I will also add my ideas during
the course of the development. :)

However, as said by Michael and Andrzej, I don't see any immediate need to
switch from plain text protocol either. For now I would prefer to stick
with plaintext protocol and extend the functionalities rather than switch
to another format entirely. Also, the communication between remote and libO
instance is relatively small since the most complicated command only have 3
parameters. Therefore the overhead caused by adding another layer will not
be ignorable. The only command that might need some extra work is the
slide_note command, maybe some simple markup that envelopes the html code
will do the work.

I agree with you about the versioning, we can add a parameter during the
handshake request so that we can keep the server-end backward compatible.

That said, I would be willing to discuss with you more into details if you
feel that JSON/XML format will improve user experience. Also, both of these
two formats have native support on included in the SDK so there wouldn't be
a great pain to switch to that.

All the best!

Siqi


2013/6/15 Michael Meeks <michael.meeks at suse.com>

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


-- 
--------

Cordialement,
Siqi LIU

Étudiant Ingérieur, Université de Technologie de Compiègne
Vice-Président de l'association robotique UTCoupe
Responsable d'atelier de ClubChine

------
  Tel. +33 7 61 16 95 83
  email: me at siqi.fr
------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130615/49911eaf/attachment.html>