<p dir="ltr">I am on board. I can use this immediately in Mythtv Player.</p>
<br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 7, 2016, 6:14 PM David Blain <<a href="mailto:David@theblains.net">David@theblains.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">><br>
> The issue is not the time to send or receive the data, but the time to<br>
parse it.<br>
> The flight time difference between binary and text data is negligible on<br>
> modern comms links.  However, low powered FE's (like tablets and phones)<br>
> have difficulty efficiently parsing structured text like XML, SOAP and<br>
JSON.<br>
> The much simpler 'Protocol Buffers' format is ideal and also provides<br>
> backwards compatibility.<br>
><br>
> Also, if we're going to replace all dbase transactions with this then<br>
there are<br>
> places, like the playbackbox and guidegrid that make heavy demands.  Over<br>
a<br>
> 5Mbps WiFi link with an ION or RPi FE, the user may well experience<br>
> noticeable delays - anything over 300mS is noticeably slow.  Even with<br>
state<br>
> of the art clients & servers, HTTP transactions can appear to be 'clunky'.<br>
><br>
> >   If the frontend performed<br>
> > lazy loading of the needed data, I don't see the advantage to going<br>
> > with a more proprietary/compact protocol.  Plus any binary protocol<br>
> > would be less resilient to changes.  We already see that with the<br>
> > current Myth Protocol (even though it's just strings).<br>
> ><br>
> > Either way, I just wanted to let you know that if a compact protocol<br>
> > ends up being required, the Service API framework can still be<br>
leveraged.<br>
><br>
> I'm just a bit worried that HTTP is over the top for what is needed.<br>
> The current Myth protocol, adapted to send & receive something like<br>
> 'Protocol Buffers' serialised data, could be very efficient.  It also<br>
minimises<br>
> the API changes so minimising development time.<br>
><br>
> --<br>
> Lawrence Rust<br>
><br>
<br>
I understand the need for a lightweight protocol on limited clients.<br>
<br>
What I have issue with is adding another completely different interface into<br>
MythtV.  Protocol Buffers looks like it's both a wire protocol and a<br>
framework to generate code for both the server and client.<br>
<br>
What I propose is that the Services API gets extended (as it was designed to<br>
do), to serialize the existing data contracts into whatever format you want.<br>
Also, a different transport can be created if everyone feels HTTP is not<br>
appropriate.  The key is to use the existing service  implementations<br>
without changing them.<br>
<br>
I'd need to research the wire format more to be sure, but we could even<br>
implement a serializer that would produce the same binary format as protocol<br>
buffers.<br>
<br>
Once again, my focus is to simplify implementing the actual services while<br>
giving clients a choice of transport protocols and message formats.  This<br>
should allow for a single service implementation which ultimately simplifies<br>
maintenance.<br>
<br>
David Blain<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
mythtv-dev mailing list<br>
<a href="mailto:mythtv-dev@mythtv.org" target="_blank">mythtv-dev@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-dev" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-dev</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br>
</blockquote></div>