[mythtv] Development task list:

[Daniel Kristjansson]

On Wed, 2005-10-05 at 13:35 -0400, Isaac Richards wrote:

> Qt _does_ include its own copy of SQLite.  If it were acceptable to go through 
> the backend for queries, this could possibly be used.
I think someone mentioned using a DB micro-kernel on the backend to
handle DB queries, I think this makes the most sense. It needs to
be in a separate thread from the regular event handling or it will
block when it doesn't need to.

> > As for Qt 4.x I'm not for this unless 3.1 compatibility is kept around
> > for a while, in which case I'm all for it.
> It'd have to be one or the other.  Qt4 gets us less of a dep on X and much 
> easier porting to windows.
A few ifdef's won't do it, huh?
It might take years for everyone to move to Qt 4.x..

> > As for incorporating the plug-ins... I'd rather see a plugin API 2.0
> > with calls added to make plug-ins embeddable, focus switchable, etc.
> I just would like to see the user interfaces for the various plugins more 
> integrated, really.  Whether that's through absorbing the plugins or another 
> method, I don't really know yet. =)
Perhaps we should look at the plug-in API of something like Mozilla?
I know it isn't perfect, but they do seem to have some well integrated
plugins.

> > [RPC slow, not securable]
> I'm just thinking about making things easier for other programs to 
> interoperate with myth, is all.
As far as I know these are the options: CORBA, DBUS, DCE, DCOM, DCOP,
Sun RPC, XML-RPC, SOAP, MBUS, ICE.

AFAIC: CORBA, DCOM and Sun RPC are not securable, DBUS is not
(yet?) networkable, XML-RPC and SOAP are fat, DCOP is not well
supported outside Linux/BSD. And, if KDE is any indication,
DCOP behaves badly after an application crash.

I don't know much about DCE, MBUS, and ICE but they do all seem to
fit the bill. DCE and ICE both claim to be securable, with the ICE
claim looking more believable as it allows secured channels.
MBUS looks like it has two levels of security, digest checking and 
secured channels. They claim to be used by Housegeist and Freevo,
which I consider a plus. My only concern is that it looks like it
is the brainchild of one person "Andreas Busching", and there 
hasn't been a release since 2004.

> > My roadmap also includes:
> > * Adding Colorkey OSD for surface limited XvMC implementations (nVidia)
> Newer cards no longer have the colorkey, just so you're aware.
I wasn't aware. Do they have more XvMC surfaces to compensate?

I wasn't planning to rip out the regular OSD anyway, it looks
better than chromakey, and Epia boxes can cope with it since
they have 16 XvMC surfaces instead of the eight with the nVidia
cards/drivers.

-- Daniel