hal-sharp / libhal C# bindings

David Zeuthen david at fubar.dk
Thu Mar 16 08:19:53 PST 2006

On Mon, 2006-03-13 at 16:21 -0500, Aaron Bockover wrote:
> I wrote a hal-sharp for use in Banshee last August, which has been
> working great thus far, but I am really not having time to do much work
> on it. It's currently in Mono SVN and actually binds libhal (apparently
> there's an older hal-sharp that uses dbus-sharp, which essentially is
> unmaintained and will be deprecated soon).
> http://svn.myrealbox.com/viewcvs/trunk/hal-sharp/
> It would be good to keep this updated and working, so if anyone is
> interested in hacking on it, please contact me.
> Maybe we could move this to HAL's FDO repo? Keeping it in Mono SVN is
> fine too.

I think it would make sense to move this to hal cvs. I've got mixed
feelings about libhal, btw

 - it's slightly less than 4000 lines of manual marshaling /
   demarshaling code in C which is ugly

 - it's not very type-safe

 - but lots of app use it (and it seems to work / not leak)

 - so we're not removing libhal anytime soon nor are we going
   to break the API (the not-so-type-safe nature of libhal and
   the very way hal exports data gives us this for free)

 - bindings are not the answer here; we want to support caching
   of properties and some apps still need a low-level interface
   and it's useful when API is not yet available in e.g. libhal-

   (but.. things like g-v-m still ought to use libhal-storage which
    is more efficient and safe (uses LibHalPropertySet / plus it's

 - libhal-storage, which is the right API for e.g. handling storage
   devices, depends on libhal

 - libhal might be useful if / when we decide to break the HAL
   D-BUS API and/or rename HAL to something else

So based on this I'd say we should go and import hal-sharp into hal CVS
as it's probably easier to maintain that way. What do you think?


[1] : the name "HAL" is just wrong for what the software does

More information about the hal mailing list