[mythtv] new protocol

[gettler at acm.org]

> >       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).
> 
> Forking the backend would seem unworkable, forking a simple protocol handler
> and you've still got to have a bulletproof protocol to talk to the master
> backend from the child process.

I did say "new process", but maybe that wasn't clear.  If I was going to
implement a new protocol, I would not put it in mythbackend.  I suppose you
may still need the protocol server to talk to mythbackend, since I would
guess that it is the authority, for example, on exactly what will be recorded.
But the current protocol could live on for that type of thing.

I agree that forking mythbackend sounds like a very bad idea.

> > I also don't want to have to change mvpmc every time someone decides to
> > change the myth protocol.
>
> This is my number one priority requirement, for things that want an exact
> protocol match, let them force it, have a protocol with at least a
> major/minor version seems like the simplest (handling multiple versions of
> the protocol on the backend usually winds up sucking pretty fast).

Historically, most of the changes I've made for protocol changes have been
adding data fields.  Since the current protocol is basically just a long
list of strings with no context, this means lots of conditional code to
know what each string means.  If we passed field/value pairs over a new
protocol, and demanded that clients ignore fields they don't know about,
the protocol would end up changing far less often.

Jon