<div dir="ltr">Hello all, <div><br></div><div style>First, it's great to have a wiki page here, I will also add my ideas during the course of the development. :)</div><div><br></div><div>However, as said by Michael and <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Andrzej,</span> 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.</div>

<div><br></div><div style>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. </div><div><br></div><div style>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. </div>

<div style><br></div><div style>All the best! </div><div style><br></div><div style>Siqi</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/15 Michael Meeks <span dir="ltr"><<a href="mailto:michael.meeks@suse.com" target="_blank">michael.meeks@suse.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Sat, 2013-06-15 at 19:14 +0300, Artur Dryomov wrote:<br>
> Yep, I already read the code in the process of preparing the wiki<br>
> page. I thought maybe something was wrong or not correct<br>
<br>
</div>        The protocol is deliberately simple; the problem space is also<br>
reasonably simple - hopefully that makes a good match :-) a plain text<br>
protocol is also hopefully readable and easy to debug. In addition -<br>
while it is easy to update Android devices to the latest version - so<br>
back-compat with old remote software is not a problem, the same is not<br>
so true for the laptop end of the piece: 100Mb+ downloads plus (on<br>
windows at least) horribly slow MSI processing to get a new version. So<br>
- I'd like to keep the remote side compatible with old LibreOffice's if<br>
possible.<br>
<div class="im"><br>
> > We actually did originally use JSON last year, but moved to a text<br>
> > based protocol to avoid having to deal with additional libraries and<br>
>> to reduce overhead,<br>
<br>
</div>        Right :-)<br>
<div class="im"><br>
> I agree about JSON, an extra dependency is not a nice solution so I<br>
> promoted XML as well.<br>
<br>
</div>        :-)<br>
<div class="im"><br>
> > I don't see any real need to switch from plain text though -- the<br>
>> commands are very simple (as most 3 parameters per command), i.e.<br>
>> easier to parse directly than through another layer.<br>
</div>...<br>
<div class="im">>> Adding another layer looks like it'll just make the code more<br>
>> complicated without any benefit. It's even been suggested to go the<br>
>> other way and use a binary protocol (although that won't play well<br>
>> with the Firefox OS remote since Javascript doesn't like binary).<br>
<br>
</div>        I tend to agree.<br>
<div class="im"><br>
> The compatibility will be broken anyway even if there will be just<br>
> extended protocol.<br>
<br>
</div>        Why ? It should be possible to accept being pushed slide thumbnails, as<br>
well as being able to request specific slides' data as/when needed -<br>
surely there is not a huge problem with that ?<br>
<div class="im"><br>
> I have plans to cut off sending information about all slides on<br>
> presentations start and it will break the current Android client<br>
<br>
</div>        Ideally we would assume that the android device can be easily updated,<br>
but the C++ side much less so - and take care to continue working with<br>
the old protocol - but of course, enable better modes of operation /<br>
newer protocols if possible.<br>
<div class="im"><br>
> Such high-level interface will allow client implementations to map<br>
> structures directly to objects. It is scalable as well — it is easy to<br>
> add a property to output when it has name, the current protocol relies<br>
> on positions as parameters identifiers so when there will be, for<br>
> example, ten parameters it will be hard to manage what position has<br>
> parameter you actually need.<br>
<br>
</div>        Of course true; plain-text is not ideal with a highly complicated very<br>
structured thing; on the other hand - we can easily add a:<br>
"complicated_command" command (or somesuch) that takes an XML blob full<br>
of impenetrable, hard to parse stuff ;-)<br>
<div class="im"><br>
> I can be too radical actually and it would be interesting to hear<br>
> other opinions. That’s why I posted this message to the mailing<br>
> list :-)<br>
<br>
</div>        I am -very- suspicious of the second-system problem. What we have<br>
works, it has some problems - but it is also rather minimal. I would<br>
really prefer not to replace it with something that is over-engineered -<br>
the best way (usually) to avoid that is to focus on the user-experience<br>
and new features to drive the low-level extensions we want; rather than<br>
the reverse :-)<br>
<br>
        That's my 2 cents anyhow,<br>
<br>
        HTH,<br>
<br>
                Michael.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<a href="mailto:michael.meeks@suse.com">michael.meeks@suse.com</a>  <><, Pseudo Engineer, itinerant idiot<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>--------</div><div><br></div><div>Cordialement,</div>Siqi LIU<div><br><div>Étudiant Ingérieur, Université de Technologie de Compiègne<br>

<div>Vice-Président de l'association robotique UTCoupe</div></div><div>Responsable d'atelier de ClubChine</div></div><div><br></div><div>------</div><div>  Tel. +33 7 61 16 95 83<br></div><div>  email: <a href="mailto:me@siqi.fr" target="_blank">me@siqi.fr</a></div>

<div>------</div></div>
</div>