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

Stuart Auchterlonie stuarta at squashedfrog.net
Fri Jan 8 09:49:27 UTC 2016


On 07/01/16 23:10, David Blain wrote:

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

I really like this idea.

As for alternatives to http, Stuart M already implmemented websockets
in the backend webserver, so there is already an alternative there.


Regards
Stuart




More information about the mythtv-dev mailing list