An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

On Tue, 2005-04-12 at 12:28 +0200, Waldo Bastian wrote:

> To address one of your other questions, in order to add notifications and 
> network transparency to KConfig I am inclined to think that some sort of 
> central service is beneficial. For notifications it's of course possible to 
> add KDirWatchers in every client process to watch for changes in config files 
> but then you still need to reverse engineer what actually changed in the 
> file. If you have send your changes to a central daemon, the only thing the 
> daemon needs to do is to forward the changeset to applications that have 
> expressed an interest. The other option is to let each individual client 
> broadcast the changes it makes to a configuration file, but that doesn't 
> scale nicely because you will end up sending changes to everyone, with that 
> approach it will be very hard to only send it to those applications that want 
> it. Such a distributed approach will also be difficult wrt keep all data in 
> sync (See KBookmark).
> 
> Compare also with   that we use in KIO to signal file operations as 
> opposed to relying on KDirWatcher. KDirNotify can provide us with semantic 
> information that we would otherwise need to reverse engineer from the changes 
> that KDirWatcher sends us.
> 
> For network transparancy I think a central approach will work better because 
> you have more control over the access pattern and can sequentialize update 
> cycles so that locking becomes less criticial. Also if your network has 
> relative high latency you want to cache as much as possible at the local 
> workstation.

I think this summarises many of the reasons why the current design is
the way it's been written on the wiki at this moment (that is, with a
daemon, and IPC and a local cache).

Therefor I added a reflowed version of these comments to the wiki:

http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs#Why_this_type_of_design

Feel free to adjust the words and sentences. I've put it at the top of
the wiki because it's ment as a sort of introduction to the rest of the
analysis. 

So it's like a "keep this in mind while you start humbling"-warning :-).

.
.
.


It's important that people understand the requirements and that people
understand that you can't build a solution if you have nothing. We will
need to rely on existing technologies that will ease the implementation,
platform independence and generation of language bindings. We will also
need to rely on existing common programming and design practices.
Etcetera.

I wouldn't participate on yet another "lets hack this together" project.
We need to carefully draw and design this application before starting
with implementing it. And we shouldn't let people who haven't been
involved in that analysis decide to much about it. They can express the
requirements, yes. I'd say they can do that now on the wiki. IMHO,
however, they shouldn't start a flamewar here.

I propose using the typical software development cycle:

1. Customer makes a requirement
2. Analyst makes a use-case
3. Customer signs that document
4. Analyst makes a functional analysis 
5. Customer signs that document
6. Analyst and programmers make a technical analysis
7. Customer signs that document
8. Analyst and programmers sit together to talk about the implementation
9. Programmers implement it
10. Customer now wants documentation
12. Documentation plan, writing documentation
13. Implementation and deployment
15. Bugfixing and maintenance
16. Etcetera 


We are just at the first stage: gathering the requirements. It's the
most important step in software development! Perhaps is the wiki a
little bit to soon with the technical choices. My apologises for that. I
didn't expect that much attention so soon (Perhaps I shouldn't have
dumped my own ideas so soon). My idea was to contact the different
project-maintainers individually and persuade them to write their
requirements on it first. I didn't expect that much reactions.

Nevertheless are all options still open.

The idea is hot and there's people interested in implementing this. Lets
now start using our intelligence. Most of us are professional computer
scientists and/or programmers. We can do this.

I'm sorry if I'm upsetting people with his. But I am convinced that yet
another flamewar on this mailinglist isn't going to help. We need to
finish "1". And no, it's not finished already. We're not even close.

I do feel that the threads and posts about this subject have matured a
little bit. I hope thats a good sign.


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.pvanhoof.be/