[mythtv] new protocol

[gettler at acm.org]

After reading some of the exchanges in this and other threads, it seems
obvious to me that we're not all on the same page.  I guess that should
not be a surprise, since we're all looking at the current myth protocol
from different perspectives.

My perspective is from writing a client on a small, low-memory, underpowered,
embedded system.  I'm never going to implement a complete myth frontend on
the mediamvp, because it would never fit.  But if I could add a few more
features, it would be a vast improvement over what I have.  I would like to
be able to add the following:

	- commercial skip list
	- cutpoints
	- GOP timecode/file offset info
	- recording schedule changes
	- program guide search
	- backend discovery

Since these features are not supported in the current protocol, it seems
sensible to consider adding them.  But since I've had numerous problems
with the current procotol, it seems like a wise idea to consider adding
a completely new protocol rather than extending the old one.  That's not
to say the old one should be removed, since it does work.

My biggest gripes about the protocol (or the mythbackend implementation)
are as follows:

	- The protocol implements version numbers, but the backend only
	  ever supports a single version.  In an architecture like this,
	  where you have a single server and multiple clients, it seems
	  sensible to put support for multiple protocol versions in the
	  server, not the client.
	- The protocol is not fault tolerant.  Any mistake, even sending
	  and old protocol version number, requires closing the connection
	  and starting over.
	- The data from the protocol is sometimes inconsistent.  For example,
	  the file sizes in the recordings list are often wrong, and need
	  to be fixed with a FILL_PROGRAM_INFO request.  Also, REQUEST_BLOCK
	  will return -1 to indicate a timeout even if it has transfered
	  some data.
	- The protocol is serialized.  I'm not sure if a blocking request
	  will actually block a non-blocking request, but even if it doesn't,
	  the client cannot tell which response goes with which request, so
	  the protocol must be used serially.
	- If a mistake in the use of the protocol causes the backend to
	  die, you lose any recordings that are currently being recorded.
	  You also cause anyone else using the protocol to lose their
	  connection.  It would seem wise that any new protocol should be
	  handled in a new process, and that new process should do a fork
	  for all connections so that faults can be isolated (much like
	  telnetd, sshd, etc).
	- There is no backend discovery.  mvpmc acts as a frontend for both
	  mythtv and replaytv.  It's too bad that it can discover all the
	  replaytv devices on a users network, but has to be told where the
	  master mythtv backend is.

So, what do you all think of that?  Most of the discussion I had seen
around this was regarding things like java, CORBA, SOAP, upnp, etc.
However, I think that's jumping the gun.  I think you need to understand
the requirements before you choose a solution.  To me it would make sense
to have a simple wire protocol that can be wrapped up in a fancy interface
for someone who wants that, or not for someone that cannot spare the
overhead.  Or maybe a server with multiple interface flavors, serving the
same data in different ways.

I also don't want to have to change mvpmc every time someone decides to
change the myth protocol.  If mvpmc was a myth frontend only, that might
work.  But since it has to work with servers other than myth, I have to
be able to support every version of myth that someone might reasonably
use.  I'm still on 0.16, and as a mvpmc user, I really don't have any
incentive to upgrade (however, as the main mvpmc developer, I really
should upgrade).  I know other myth users who are still on 0.15, since
for them, it works just fine.

Anyway, sorry if this is all just noise to everyone.  But since I'm seeing
new people start down the path of communicating with myth, it seemed like
a good time to bring up the idea of improving the communication method.
No sense in letting others take months to find all the shortcomings that
I already know about.

Thanks.

Jon

> --===============2094792524==
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> > 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
> 
> 
> --===============2094792524==
> Content-Type: text/plain; charset="iso-8859-1"
> MIME-Version: 1.0
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 
> --===============2094792524==--