common caching mechanism for xfdesktop and xfce4-appfinder

Eduard Roccatello eduard at xfce.org
Sat May 14 14:11:05 CEST 2005


Brian J. Tarricone wrote:

>1) It should be stored in an mmap()able file.  This means a binary
>format, and the easiest way is probably to just design a struct which
>is sized and populated using the least common denominator of
>...
>  
>
I agree!

>2) It should be stored in host byte order for performance reasons.
>This means that the cache file won't be shareable among platforms with
>different byte orders.  However, we might be able to design around
>this, as most .desktop data is string data.  Boolean values can be
>treated as 32-bit integers such that TRUE=0xffffffff and FALSE=0x0.
>This really needs some more thought and fleshing out.
>  
>
Uhm, i think byte order is important for supporting lil-end e big-end 
platforms so
i agree with you. Can you explain better what do you think about this 
point? thanks! :-)

>3) Should it be a per-user or systemwide cache?  Or should there be
>both?
>...
>  
>
I prefer per-user cache only. More mem and disk space wasted but better 
imho.

>4) Transparency.  I don't think we should bother if updating the cache
>requires manual intervention.  That's a big step backward, IMHO.
>However, updating it automatically it difficult.  If the cache is out
>of date, how do we make sure only one app tries to update the cache?
>How do we ensure that other apps mmap()ing the file don't get
>corrupted data?
>  
>
Cache is a red critical zone. This is a reader-writer problem and should 
be avoided
with semaphore and so on... But how to notify changes if automatic? 
Should be manual?
Uhm we need to discuss about it more and more...

>5) Should probably look what the fd.o folks are doing with the icon
>theme cache - I'm sure we can reuse most (if not all) of their ideas.
>
>  
>
I agree. As Biju suggest i think we should submit any spec to fd.o :-)

--
Cheers,
Eduard



More information about the Xfce4-dev mailing list