gconf question

[John Galloway]

On Jul 12, 2006, at 12:55 PM, David Zeuthen wrote:

> On Wed, 2006-07-12 at 12:38 -0700, John Galloway wrote:
>>> Btw, I'm curious what the problem with pulling in gconf, gnome- 
>>> keyring
>>> etc. here is?
>>
>> We're not a gnome desktop.  Its palmsource, so we're making a  
>> handheld
>> system (all announced now, but I never bothered to re-subscribe under
>> my palmsource account) based on linux but providing a palmOS-ish user
>> experience and apps.
>
> Interesting, sounds very cool.
We think so! :-)
>
>>   Gconf did not provide the security we needed to
>> use it for everything (i.e. including device management stuff  
>> pushed out
>> by the carrier) and user application stuff, so we wrote our own  
>> settings
>> system.  Likewise gnome does not offer what we need for the tiny  
>> screen
>> type usage, so its not in play either.  HAL does offer good stuff  
>> and we
>> are using it and would like to continue to do so, maybe increasing  
>> such
>> (i.e. now its just pluggable media, but we've been looking at  
>> other hw
>> mgt issues where we could leverage HAL).  But the more a desktop env
>> is required, the less likely this will become.  Its also a very  
>> memory
>> constrained environment so pulling in anything we don't actually  
>> use is
>> very undesirable.
>
> Oh, OK, that provides much needed perspective. Thanks.
>
> So I think you're in good shape here and what you should do for  
> mounting
> is just write your own mount program that
>
>  a. reads settings (such as mount point, mount options, etc.) from  
> your
>     own preferences source
>
>  b. calls into HAL to actually do the mounting
>
> much like gnome-mount does. Depending on your needs, this could  
> even be
> in the same codebase as your file manager and it could invoke these
> methods on HAL in response to events from HAL saying there's a new
> volume available etc. (much like gnome-volume-manageR). This approach
> would be pretty lean and also, I think, easy to implement.
Now, because we need to support PalmOS-like APIs to apps about volumes
we have a daemon that gets HAL add/remove events and does the needed  
stuff to pass
that along, and it mounts as needed whle also getting mount status  
changes (that it
might have caused).  So when we upgrade we should be able to take the  
middle
chunk out and let HAL mount for us.

The format device just makes me tingle all over :-)  Doing formating  
on the
handheld from the outside HAL and dealing with the distrubance that  
causes HAL
(espeically with 0.5.5.1 that sometimes gets its evens out of order  
so e.g.
a partprobe can cause it to see an add for a device it already has,  
thus ignored
then it seems the remove and the device now is gone, oops.  But not  
too hard
to fix (haven't submitted those changes since the whole sequence  
issue is
resolved via udev in 0.5.7, but would be happy to do so if anyone is  
interested).
So getting HAL to do this and keep quite about "internal events"  
would be great.
>
> It's a bit more complex if you want to handle passworded media using
> LUKS but still entirely doable (gnome-mount does this already).
>
> Oh, and if you (or anyone else such as Nokia, GPE, OLPC etc.) have any
> requests about HAL being too slow / too memory consuming for embedded
> use please come forward with them. Or if you have feature requests  
> such
> as FormatVolume(), PartitionDisk() (we already want to add these) come
> forward as well. I really want HAL to work on embedded systems and  
> if it
> doesn't do that too well now I want to fix it.
Great!  I'd by happy to be more of a contributor but we are bit down  
rev at
the moment.  HAL's size IS an issue for us for sure, it fits but the  
smaller
the better.  We're also looking at it for battery/power mgt though  
its focus
on ACPI is not great (though understandable).
  -jrg
>
>     David
>
>
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal
>