<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi,<br>
      On 13/06/13 19:32, Artur Dryomov wrote:<br>
    </div>
    <blockquote
      cite="mid:E193CD4E-A1BE-4794-869D-1B44931353E9@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      Hi All,
      <div><br>
      </div>
      <div>I have created a wiki page where I moved some information
        from Git and placed some thoughts about the Impress remote
        protocol.</div>
      <div><br>
      </div>
      <div><a moz-do-not-send="true"
          href="https://wiki.documentfoundation.org/Impress_Remote_Protocol">https://wiki.documentfoundation.org/Impress_Remote_Protocol</a></div>
      <div><br>
      </div>
      <div>It would be really great if Andrzej could improve the
        information about the first version of protocol.</div>
      <div>Probably there are other commands — like pairing ones — that
        are missed. But I can be wrong :-)</div>
    </blockquote>
    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.<br>
    <br>
    <blockquote
      cite="mid:E193CD4E-A1BE-4794-869D-1B44931353E9@gmail.com"
      type="cite">
      <div><br>
      </div>
      <div>This page contains my proposal of the second version of
        protocol as well.</div>
      <div>It would be interesting to see other proposals and hear
        thoughts and opinions.</div>
    </blockquote>
    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.)<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    <blockquote
      cite="mid:E193CD4E-A1BE-4794-869D-1B44931353E9@gmail.com"
      type="cite">
      <div>I’ll read Google Play reviews soon to find out new feature
        requests.</div>
      <div>BTW — is it possible to get the access to the Android
        developer console?</div>
      <div>Google Play shows reviews for a current language only, the
        developer console can show all reviews at once.</div>
    </blockquote>
    No idea -- I'm not entirely certain who controls the TDF Play
    account.<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    ATB,<br>
    <br>
        Andrzej<br>
  </body>
</html>