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

Lawrence Rust lvr at softsystem.co.uk
Fri Jan 8 10:01:44 UTC 2016


On Thu, 2016-01-07 at 18:10 -0500, David Blain 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.

Not a 'completely different interface' but to extend the existing.  I
was proposing to keep the existing Myth protocol (for backwards
compatibility) and add a new serialisation method (Protocol Buffers)
that is both more compact, easier to parse and has tags to enable
version compatibility without special case coding.

>   Protocol Buffers looks like it's both a wire protocol and a
> framework to generate code for both the server and client.

The framework is similar to IDL for DCOM.

> 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.

That sounds promising.

> Also, a different transport can be created if everyone feels HTTP is not
> appropriate.

I believe that 'RFC compliant' HTTP is not right for Myth for these
reasons:

- It's transaction orientated.  This doesn't fit easily with Myth's
'Event' broadcast mechanism.

- The request and headers are in human readable form and need additional
parsing, unlike Protocol Buffers.

- It has no mechanism (like STARTTLS) to upgrade to a secure connection
(HTTPS requires an additional dedicated port).  All communications
should be encrypted in today's age.

However, HTTP has some advantages that we could leverage.  If we used
custom request methods with 'Protocol Buffers' encoding of the request &
headers then I think it could be ideal.

>   The key is to use the existing service  implementations
> without changing them.

Agreed.

> 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.

The 'Protocol Buffers' serialisation is very simple.  The important
feature that it provides is a compiler that allows easy definition of
shared data and a library to de/serialise from/to std::string.  We don't
need to use the compiler but I would recommend the wire protocol.

> 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.

Agreed.

-- 
Lawrence Rust



More information about the mythtv-dev mailing list