[mythtv] MythTV: Isaac Tivo: > 100 tech guys
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..
More information about the mythtv-dev