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

[David Blain]

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