icons for Settings Manager

[edscott wilson garcia]

On Wed, 2004-01-14 at 16:42, Benedikt Meurer wrote:
> 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?

Well, it does seem harder than expected. We could start piece by piece
and see how it evolves (or becomes extinct ;) I'm still trying to figure
out the glib xml parser...

regards

> 
> regards,
> Benedikt