[mythtv] {Spam?} Re: Backwards compatibility

[Lawrence Rust]

On Thu, 2016-01-07 at 11:25 -0500, David Blain wrote:
> > 
> > David,
> > 
> > Thanks for your thoughts.
> > 
> > Agreed, reflecting all FE database requests to the master BE is the way
> > forward.  The down side is latency so the mechanism has to be fast and
> > caching and cache coherency have to be up to scratch.
> > 
> > I don't want to re-invent the wheel so I'd like to use an existing
> lightweight
> > RPC mechanism (something that doesn't use JSON or XML etc).
> > The Myth protocol, although clunky, looks as if it better fits those
> > requirements.  I'm not familiar with the services API but at 1st looks it
> > appears to have much higher overhead and latency.  Please correct me if
> I'm
> > mistaken...
> > 
> > --
> > Lawrence Rust
> > 
> 
> Lawrence,
> 
> Just so you know, I designed the Service API framework to support multiple
> Transport Protocols & serialization types.  Currently only HTTP (with
> support for SOAP) is used for transport, and XML, JSON & xmlplist are the
> implemented serializers.
> 
> It wouldn't be difficult to implement a more compact serialization and
> transport protocol without having to change any of the exposed services.
> 
> That said, I question the need for it.  If the frontend was made to access
> all data through the services API, what time critical code does it run that
> it would need to save the few bytes of bandwidth?

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