hal-sharp / libhal C# bindings

[David Zeuthen]

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-
   storage

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

 - 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?

Cheers,
David

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