hal-sharp / libhal C# bindings

[Aaron Bockover]

My main reason for going the libhal route for the bindings was that
dbus-sharp were immature, and will be replaced with a new version in the
future that uses generics. When dbus-sharp was started DBus itself was
immature, and as it grew, the bindings basically started to rot. 

The API for hal-sharp doesn't need to change, but when the time is
right, the implementation can switch to DBus.

So if you think it should be in HAL CVS, then I'm down for moving it.

Cheers,
Aaron




On Thu, 2006-03-16 at 11:19 -0500, David Zeuthen wrote:
> 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
> 
> 
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal