[mythtv] NEW MythPlugin functionality (PATCH)

[Joseph A. Caputo]

Hmmm... I suppose so... this is my first foray into the world of dynamic
object loading, but I would think that you could do almost anything in a
plugin that you could do in the monolithic code, given an appropriate API.
The real consideration is to weigh the costs vs benefits of doing something
as a plugin versus putting it directly into the code base.  Reasons for
doing things as plugins include:

- doesn't require write-access to the main code base (usually not a problem
with open-source projects)
- module requires/benefits from access to main program's run-time data,
where IPC would be too complicated/costly (plus, see first reason above)
- 'neatness': not having to spawn/exec too many separate processes
- Reduced startup cost for frequently-used plugins: library only needs to be
loaded once, vs. exec-ing a new process every time the module is called

Reasons against implementing something as a plugin:

- Plugin code may have access to & potential to corrupt main application
data/state.
- Bugs in plugin could affect/crash entire main application (here,
mythfrontend)

I'm thinking that, in the context of Myth, encoding/decoding type processing
doesn't make sense as a plugin, nor does anything tied directly to
functionality that is part of the core
libmyth/libmythtv/mythfrontend/mythbackend.  It may, however, be useful for
future modules (MythBurn, MythBlender, MythKitchenSink, etc.) to consider a
plugin-based implementation.  The nice thing about setting up a module as a
plugin is that you could still make it a standalone executable by writing a
simple main() wrapper.

-Joe C.

> -----Original Message-----
> From: mythtv-dev-bounces at snowman.net
> [mailto:mythtv-dev-bounces at snowman.net]On Behalf Of Edward Wildgoose
> Sent: Wednesday, April 09, 2003 5:05 AM
> To: Development of mythtv
> Subject: RE: [mythtv] NEW MythPlugin functionality (PATCH)
>
> Excellent idea.
>
> Do you think this is a sensible way to add other stuff like audio
> or video filters to the tv as well?  Running a denoise filter
> (temporal for preference) for example on analogue tv would be
> pretty CPU heavy, but should give a pretty big increase in
> compression (as well as looking better)