[mythtv] MythTV: Isaac Tivo: > 100 tech guys

Isaac Richards ijr at case.edu
Wed Dec 8 05:12:03 UTC 2004


On Tuesday 07 December 2004 11:26 pm, Kevin Elliott wrote:
> I can recall many times on IRC when you've explicitly stated that you will
> not accept
> code that is slower than existing code, regardless if it's even just a
> fraction of a second
> slower in total and adds new functionality. Certainly optimization and
> performance is
> important, but where is the line drawn?

Only thing that comes to mind is the MediaMVP people wanting to change the 
backend protocol to use XML.  I just won't have that, since it's be waay too 
ugly and slow.  I think there's a difference between that (not wanting 
something that's complicated, completely unnecessary, and a few hundred times 
slower than the existing code) and rejecting code or a design that's just 
'slower'.  Case in point is the new hdtv recorder code that DTK's been 
working on, and I just merged in.  It's doing quite a bit more than the old 
code, so it is slower.  Any time someone adds an optional behavior or 
feature, things get ever so slightly slower...

'Course, it seems that the MediaMVP people just didn't want to link to 
libmysqlclient for direct DB access, so the whole thing was silly.  It's a 
tiny library. =)

> So you would be willing to work with / allow people to implement
> interaction between modules?

Of course.  As I said, there's absolutely nothing in the source preventing it.

>     1) Over complicated "plugin" design

What's so complicated about it?  The main plugin interface is 3 functions: 
init, config, and run.  Plugins can use as much or as little of the 
functionality provided by libmyth as they want.  'Course, more's better, 
since the plugin fits in better, but...
 
>     2) No solid and documented module interaction system to allow MythX to
>         run and be controlled by MythY.

That's because the 'module interaction system' is just standard Qt 
customEvents, which I think are sufficiently documented by Trolltech. =)

>     3) Heavy dependancy requirements

Such as?  I've not added a single dependency in a very long time, and even got 
rid of a _lot_ of stuff (xvmltv) with the built-in datadirect grabber (at 
least for US/CA users).  There are a bunch of libs that are optional.

>     4) Lack of any development documentation, guides and API specifications

Well, that's because I don't have time. =)  I also tend to believe that 
well-written code is better documentation than half-written, out of date docs 
(which most such docs for opensource projects are).

> Isaac, would you be interested in holding a "MythTV Conference Meeting" on
> IRC a
> specific date/time to discuss current goals and potential development
> shifts? Perhaps
> this could be useful to help in coordinating development efforts?

Sure, I could do that.  'When' doesn't matter too terribly much to me..

Isaac


More information about the mythtv-dev mailing list