icons for Settings Manager

[Benedikt Meurer]

edscott wilson garcia wrote:
> On Wed, 2004-01-14 at 12:20, Benedikt Meurer wrote:
> 
> 
>>Glib XML Parser is a light-weight SAX-style parser which should be quite ok 
>>for our needs. I thought of letting mime-things be handled by a daemon process 
>>and having a small communication library for setting up a fast UD socket and 
>>retrieving the information from the daemon. This approach has some advantages, 
>>just to name 2 of them (while it has some disadvantages of course):
>>
>>1) Mime config/icon files can be held/cached in memory in the daemon process 
>>and need not to be parsed whenever information is required, that should lower 
>>the I/O overhead and allow for faster operation (depending on the quality of 
>>the UD socket implementation in the target system)
>>
>>2) Processes load only a thin wrapper library with only the socket code.
> 
> 
> I like this idea. Currently each process has to parse the xml and create
> it's own g_hash_tables. Startup times can certainly be reduced if only
> one copy of the g_hash_tables is used (except for the first application
> which requires and therefore starts the daemon). We only need to be
> careful to resolve race conditions when two different applications both
> try to start the daemon at the same time.

Starting the daemon should be quite easy using a locking technique similar to 
shlock(1):

1) try to connect
2) if that fails, shlock on a well-known lockfile
3) gathered lock: try to connect (maybe someone else started the daemon in the 
meantime)
4) if that fails, start the daemon
5) unlock the lockfile

Step 1) is optional, but allows for faster startup if daemon is already 
running (safes the lock()/unlock() procedure which is quite expensive for 
shlocks). We could also use SYSV Semaphores (see sem_open(3)), but they are 
not supported very well by all systems, so they could be first choice but with 
a fallback to generic shlocks.

>>Using SYSV shm and IPC techniques could allow us to speed up the stuff even 
>>more, for example transferring pixbufs between processes using shm segments.
> 
> Or maybe have the daemon place its g_hash_tables and icon factories in
> shared memory segments so applications can access them directly. 

The problem with g_hash_tables is that data is allocated on the heap 
internally which is therefore not shared in the shm segment and pointers would 
not be valid in the context of another application that maps the same shm 
segment. To make it even harder, the virtual address of the shm segment is not 
garantied to be mapped to the same address in all applications, so pointers 
even within the shm segment are useless and dangerous. Therefore we would have 
to develop our own data structures and algorithms if we'd decide to use shared 
memory techniques.

>>But this was just a thought I had last year while I was looking for an easy 
>>and efficient way to bring MIME to XFce. Any comments to this?
> 
> Your ideas sound very good. At the moment I don't know how difficult
> they would be to implement. It certainly sounds interesting to try and
> do.

Actually I dropped that idea because at that time I thought it'd be to 
difficult to develop. Whereas I think the implementation should be quite easy, 
but the analysis and design steps could take a lot of time and energy, since 
we would have to develop

a) a flexible and easy to implement wrapper API
b) a fast and flexible data exchange layer (esp. in terms of SHM w/ fallbacks 
and error handling/recovery)
c) a stable and fast backend (the actual daemon)

Only looking at c), speaking of things like security (esp. authentication), 
portability (different socket implementations, different shared memory 
techniques), performance and stability (its a daemon!) makes me believe that 
this is indeed a non-trivial task.

And if we should really decide to give this a go, then we should propably 
think of adding things like .desktop file handling and configuration handling 
to this framework as well, so that we have (nearly) all parsing of files in 
one central daemon (using several caching techniques to speed things up) 
instead of having each application parse several files each time it fires up.

 From what I think, the fact that we are "distributed all over the planet" 
makes things even harder, cause we cannot just sit down in front of the 
whiteboard and discuss various solutions using well-known modelling 
techniques; and I'm not sure if this can be done as a one-man-job.

Anyway I still think that this is a good-to-have with XFce. Having a single 
process that handles configuration and all kinds of meta-information should 
increase the quality and maintanability of XFce a lot. For example, if we 
implement our own configuration framework on top of this new architecture 
using our own XML backend at this time, we could later on switch to D-BUS, 
GConf or whatever system by simply modifiying one module in one application 
instead of having to alter nearly every application. We could also provide 
different configuration backends for XFce by default.

Anyway, everybody should be clear that this is not an easy task to finish and 
will take several months (esp. since we are all busy with other things and of 
course with XFce components, jasper with the panel, edscott with xffm, botsie 
with <dont-know>, olivier with everything and I am currently breaking the 
session manager again).

(Lots of words but nothing really said :-)

Comments?

regards,
Benedikt

-- 
NetBSD Operating system:                       http://www.NetBSD.org/
pkgsrc "Work in progress":                  http://pkgsrc-wip.sf.net/
XFce desktop environment:                        http://www.xfce.org/
German Unix-AG Association:                   http://www.unix-ag.org/
os-network:                                 http://www.os-network.de/

OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg