[mythtv] {Spam?} Re: Backwards compatibility

[Daniel Frey]

On Thu, Jan 7, 2016 at 11:28 AM David Blain <David at theblains.net> 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?  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
>
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


I would consider Protocol Buffers especially for mobile client interation
via the services api.

https://developers.google.com/protocol-buffers/?hl=en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20160107/897063da/attachment.html>