[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