icons for Settings Manager
edscott wilson garcia
edscott at xfce.org
Thu Jan 15 05:17:29 CET 2004
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
> 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
> 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 :-)
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...
More information about the Xfce4-dev