Addons

[David Zeuthen]

On Tue, 2004-12-14 at 00:50 +0000, Sergey Udaltsov wrote:
> Hello
> 
> Just some general thoughs regarding addons and related properties
> (just some food for thought, very far from beeing considered as an
> attempt to specify something).
> 
> I think, there should be some different policies for the addons
> invocation and termination. Possible evident variants:
> 
> - Launch the instance of addon for every attached device - and kill
> (sending probably SIGUSR1?) on the device unplug.
> 

Basically, yeah. 

> - Launch the instance of the addon for the first device within some
> group - and kill once the last member of the group is unplugged (is it
> useful in any way?)
> 

I'm not sure this is useful - for interesting devices that makes sense
for addons, running an extra copy isn't a big deal. There won't be too
many of them either.

> - Launch single, per-system, instance of the addon once first device
> is plugged (requiring this addon) - and killing when the last is gone
> 

Probably not useful either; an addon may implement it's one "Am I
running" checks.

> - Start on hald startup, stop on hald shutdown.
> 

If this is the case one can just merge properties on the root computer
hal device object.

> Probably, there can be other variants, combinations. So what I see
> here is three properties:
> 
> - info.software.addons.path (string) - the path to the binary executable
> - info.software.addons.policy (string) - one of the predefined policyt names
> - info.software.addons.group (string) - optional, the name of the group
> 
> The policies should be supported by the hald and libhal - so minimal
> coding on the addon side is required. I think manually coding these
> things in each addon is not a WTG.
> 

I'm not sure this covers the cases where a device object has several
capabilities (e.g. functional elements). Instead it should probably look
like

 info.software.addons.input.mouse.wireless_battery

for polling on wireless mice battery and e.g. 

 info.software.addons.something_else

for polling on something else. A more realistic example is this

 info.software.addons.block.media_polling
 info.software.addons.block.battery_poll

for a wireless USB harddisk :-). So, if I'm a open source project (or an
OEM) I can just do info.software.addons.block.battery_poll=hal-battery-
poll-for-specific-harddisk from a .fdi file.

The process managing life cycles would scan the info.software.addons.*
properties and do the right thing for each of them on device add/remove.

Cheers,
David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal