Addons

[Sergey Udaltsov]

> 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.
Well, generally I agree. Even is useful, this is some exotic
situation. I just was concerned about performance implications related
to starting separate process for each device. So initially this can be
skipped - till it is really necessary.

> > - 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.
Exactly what I mean. If libhal could provide some small function
implementing this - it would save some copy/paste work.

> > - 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.
Well, what is these properties should be monitored - the addon should
be running all the way.

> I'm not sure this covers the cases where a device object has several
> capabilities (e.g. functional elements). Instead it should probably look
Yeah, good point. Device can require several addons. Then,

info.software.addons.input.mouse.wireless_battery
and
info.software.addons.input.mouse.wireless_battery.policy

> 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.
Yeah, this is perfectly ok.

My point is that it can be handy to have the addon lifecycle concept -
depending on the policy. And addon should not bother too much about it
- it should just use appropriate interfaces. Moreover, I would even
generalize "polling" addons (event-driven ones are a bit more
difficult to generalize - but probably there are some ways). So, in
the battery case, the addon would provide some "vtable" with three
functions:
- init
- term
- poll_all_devices (this function makes sense for "one process for all
devices" scenario)
- device_added
- device_removed
For "process per device" scenario, "poll_device" handler should be
provided instead.

I think, creating some easy-to-use framework for the addons
development is a reasonable goal.

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