[mythtv] {Spam?} Re: {Spam?} Re: Backwards compatibility

[Daniel Frey]

I am on board. I can use this immediately in Mythtv Player.

On Thu, Jan 7, 2016, 6:14 PM David Blain <David at theblains.net> wrote:

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