[mythtv] Protocol negotiation?

[Geoffrey Kruse]

On Sep 29, 2006, at 11:53 AM, Paul Bender wrote:

> Michael Tiller wrote:
>> It seems like every time there is an update to MythTV, it creates  
>> havoc
>> with all other clients.  In my case, I have a MediaMVP and an XBox
>> running XBMC but the issue also exists because when trying to run  
>> MythTV
>> on Xebian as well because some people (like me) prefer to have  
>> prebuilt
>> distributions and those often lag significantly.
>>
>> I'm curious...wouldn't it be possible to have the MythTV backend
>> negotiate which protocol to support?  In that way if it ran across an
>> "old" client that wanted protocol level 30, it could say "OK, I'll  
>> talk
>> to you with 30" insteady of throwing protocol errors.
>>
>> I suppose since the current protocol doesn't support this kind of
>> handshaking we'd have to bump the change the protocol thereby
>> (temporarily) exacerbating the situation. :-)  But it seems like a  
>> good
>> way to go in the long term because then it wouldn't force you to  
>> update
>> all clients at the same time.
>>
>> Just a thought.
>
>  From experience, I can tell you that it is often a lot of effort to
> make sure that older protocol versions still work when you extend or
> replace protocols. I would much rather MythTV developers spend time  
> move
> things forward than looking back.
>
I think it could be done quite simply...
The myth protocol is basically a series of strings separated by a  
token ([[::]] if I remember correctly).  Why not just add the  
protocol version of each token to the separator ( [[::30::]]Some Data 
[[::31::]]New Data ...)  That way, the parser just simply throws out  
any tokens that have a number higher than it understands in the  
separator.  I think this would be fairly straight forward to  
implement.  Of course, there would have to be tolerance for missing  
fields if a newer version of the protocol were to remove elements,  
but this also should be trivial.  Since the myth protocol is already  
very string heavy and not very efficient, I think adding a few  
characters to each separator would not be much of a performance hit.

As far as not -having- to upgrade, I run a linux backend and two mac  
frontends, one intel and one ppc.  Often there is a critical fix for  
the backend, however in the meantime, a bug or compile error has been  
introduced in the mac version of the frontend that prevents me from  
using the same version.

Just my $0.02

Geoff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2415 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20060929/bd541776/attachment.bin