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@suse.com <><, Pseudo Engineer, itinerant idiot
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.