[mythtv] {Spam?} Re: Backwards compatibility

[David Blain]

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

David Blain