KIconLoader Followup
Luke Alan Sandell <[email protected]> Mon, 06 Jun 2005 21:08:46 -0400
| Newsgroups | gmane.comp.kde.devel.optimize |
|---|---|
| Message-ID | <[email protected]> |
First, I would like to thank everyone who responded to my previous post. I never expected so many responses so quickly. Since I composed that message it has been revealed to me that Google is only allowing 200 participants in their program (forgive me, I was not even aware of the program until it was announced on dot.kde.org). In practical terms, this means that if I want to actually have my proposal accepted, it will have to be something a little more earth-shattering than a cache for KIconLoader. To this end, I have sent a proposal to [email protected], being graphical editors for kcfg and kxmlgui, though even this seems to have limited usefulness. All this means that I will no longer plan on doing anything with the icon loader per se. However, while we're discussing this, let me put in my $0.02. I have read over the replies, and there seems to be two recurring themes. This is not just an issue for KIconLoader; I see other classes that could potentially share data across applications, such as KStandardDirs. 1. Shared memory _cannot_ be used, because it needs to be synchronized. If individual processes handle the synchronization, there is the prospect of desktop-wide deadlock if one of them crashes during a data access (can you say "Windows"?). Therefore, some sort of "server" must be used to synchronize accesses, even if it is as simple as a dcop service. 2. A problem with sharing data between applications is that even if applications use the same data 99.9% of the time, there is always the possibility of an application doing something differently (adding a icon path, for instance). For this reason, if data sharing is to take place between applications, the class that facilitates the sharing must distinguish between application and system-wide data, hiding the former in the individual application but sharing the latter. Now, what there really needs to be is a set of classes for sharing data (not memory) between applications, because no library developer is going to want to explicitly create a client/server every time (s)he wants to share something. Perhaps that is something I could run with... Regards, Luke Sandell