[mythtv] Development task list:

[Isaac Richards]

On Wednesday 05 October 2005 08:38 am, Daniel Kristjansson wrote:
> On Wed, 2005-10-05 at 04:12 -0400, Isaac Richards wrote:
> > Just wrote up a short list of tasks that I think would be good directions
> > for myth to go in:
> > http://cvs.mythtv.org/trac/wiki/FutureDevelopment
>
> The zeroconf/rendevous has been on my roadmap for a while, I see it as
> part of making MythTV easier to set-up. It eliminates the need to know
> IP addresses on the 95% of home networks it works on; which comprises
> almost all the people who think, IP address, wha?
>
> I would really like MythTV to be something my completely non-technical
> in-laws could install, so I'm also interested in the SQL abstraction as
> it might allow a simple linkable DB, like Berkeley DB.

Qt _does_ include its own copy of SQLite.  If it were acceptable to go through 
the backend for queries, this could possibly be used.

> The UI rewrite is also needed, if only as a cruft removal process.
> The OpenGL rendering is neat too of course.

Yup.  Getting rid of of the cruft that's built up in the UI code is one of my 
biggest goals with the UI rewrite.

> A more often updated website would be good...
>
> 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.

> 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. =)

> Changing the RPC protocol isn't high on my list, I've used CORBA,
> DCOM+, and their kin. The love affair does not last long, and you
> can't fix the performance bugs since they are in someone else's code.
> If someone decides to use it as a public protocol the user has to
> make MythTV internals public too to use the popular protocol, think
> NFS when that RPC protocol was still used by others. The MythTV
> internals were not designed to be secure against attacks. Making
> them secure would be a huge, performance degrading, undertaking.

I'm just thinking about making things easier for other programs to 
interoperate with myth, is all.

> 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.

> * Documenting everything
> * Improving text input by remote/joystick (post-MythUI, for gfx)
> * Merging the DVB and HDTV recorder parsers
> * Adding some parsing on the frontend to detect subtitle/audio language,
>   detect aspect ratio, handle DSM-CC, etc.

Go add stuff to the list. =)

Isaac