[Nut-upsdev] naming a new Mac OS X UPS driver

[Arnaud Quette]

2011/8/28 Charles Lepple <clepple at gmail.com>

> On Aug 27, 2011, at 6:46 AM, Arnaud Quette wrote:
>
>  this is very similar to the HAL / UPower (using the system provided PM
>> integration)!
>> but you have a converse approach: consume data from this source.
>> does this means that using this source is better (in terms of data and
>> features provided)?
>>
>
> Fewer features, but easier to implement. It's really more of a monitoring
> interface, since the OS GUI provides a number of different shutdown
> thresholds.
>
>
>  and / or that NUT drivers can't replace (as with UPower) OS X' one(s)?
>>
>
> This is what got me looking at HIDAPI: the HID driver in OS X makes it hard
> to grab a HID device/interface with libhid.
>
> Then again, since HIDAPI doesn't deal with HID usage paths, I might be able
> to code up some alternate HID stuff for NUT that uses the native OS X HID
> interface now that I'm a bit more familiar with that code. I need a
> sabbatical :-)


that would probably be better (both the use of the native OS X HID interface
and the sabbatical ;-)


>
>  is this still limited to USB HID?
>>
>
> I think the OS only supports USB HID, but it would be possible to write a
> bridge that goes the other way to let the OS see UPS status for a serial or
> network UPS. I think it would be best implemented as an upsd client.


not sure, see below.


>  my last idea on UPower (and similar needs) was to change the driver dstate
>> layer (which is used for communication with upsd) to a plugin system style.
>> the default would still be to load the classic dstate. but alternative would
>> be provided for DBus / UPower and any other kind of useful protocols.
>>
>
> Personal preference: I don't like plugin interfaces where only one
> interface is used at a time. The HAL drivers just linked in a different
> dstate layer at compile time - wouldn't that work?
>

you got me wrong: conversely to the hal drivers, which used a kind of static
plugin system at compile time, here, we would be able to use multiple
plugins.
so that you could, at the same time, both report to upsd and other things
like upowerd, OS X power daemon, ... this could be a better way in the long
run, don't you think?

so if your idea is quick and easy to implement, let's go ahead.
in the meantime, let's continue to talk on this plugins backend, and see if
it fits the needs.

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110828/197790fe/attachment-0001.html>