[mythtv] new protocol

[Anduin Withers]

> Well, myth would probably need 2 protocols in any event because the RPC
> protocols like SOAP etc. don't really do streaming per se, do they?

Yes, this is what I was getting at with the UPnP stuff, I consider having a
separate streaming protocol a given.

> But tell us why your above proposal makes sense?  I mean SQL is not
> that heavyweight of a protocol (probably lighter than SOAP) and there's
> a lot of effort to make SQL client libraries for lots of platforms, so
> what is the benefit of having to have a protocol to ask the backend to
> do queries for you and reformat the results to send back to you if you
> can do it to the DB easily enough?  Is it that you can't do it to the DB
> on some platforms, but you could do SOAP or CORBA or other queries?

It isn't the availability of a DB client library that I'm worried about, I'd
like to see a protocol that didn't require the DB to be directly accessible
by all clients. Why? Firewalls for one (yes, at some point I'd like to see
the ability for clients to be forced to authenticate as well), a single,
controllable access point for another. 

Yes, in some cases it is blindingly stupid to toss SQL out, I'm not
proposing that. However many of the protocol changes so far have affected
all clients unnecessarily, how many times was the protocol changed,
requiring an update to mythweb even though it didn't care about the change? 

There have been, and likely will continue to be a number of architectural
changes that could be transparent to many clients if they weren't doing
direct DB access.

My largest gripe with the current protocol is actually a very simple one; it
sends position dependent data instead of name/value pairs. This causes,
often, needless updates to anything using that portion of the protocol.

I'm certainly not claiming it is going to be faster, or that everything
should be forced to use it, but it should be available.

-- 
Anduin Withers