[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [Kde-pim] Re: CIA proposal (was: ClientInterface)
From:       Don Sanders <sanders () kde ! org>
Date:       2003-07-30 5:51:19
[Download RAW message or body]

On Wednesday 30 July 2003 09:27, Ingo Klöcker wrote:
> On Tuesday 29 July 2003 09:02, Don Sanders wrote:
> > On Tuesday 29 July 2003 09:20, Ingo Klöcker wrote:
> > > On Monday 28 July 2003 01:59, Don Sanders wrote:
> > > > Even if a client doesn't allow network config changes to be
> > > > made, that client will still rewrite the network config state
> > > > at application shutdown. This is because currently all KMail
> > > > clients are designed to write all network config prefs at
> > > > shutdown.
> > >
> > > Yeah, and that's pretty stupid, isn't it? Especially the
> > > network configuration only has to be written after it has been
> > > changed. And it's only changed when the account's configuration
> > > is editted or when the user has entered the account's password
> > > (in case he wants the password to be stored in the config
> > > file).
> >
> > I don't think that writing application data at shutdown is
> > stupid. It's the standard KDE design to write settings on
> > application shutdown. It's simple, efficient and flexible.
> > KOrganizer, KNode, KAddressBook and KMail all work this way. (I
> > can back that assertion up with a detailed code review it you'd
> > like).
>
> Yeah right. Just because other apps do it, that doesn't mean that's
> it's good practice. For KUniqueApplications this is okay. But for
> normal applications which can be started multiple times this is not
> okay. Just for your information: Konsole, Konqueror and other
> non-unique applications store their configuration on session exit
> in special config files (one file per instance of the application).
> So those applications will never be affected by the above problem
> because the shared configuration file is only saved if it's
> explicitely saved but not on session exit.

Konsole and Konqueror are affected by the challenge of having mutliple 
processes updating the same (config) file, and they solve it in 
different ways.

Konsole configuration is a good example of what I don't want KMail to 
be like. I don't want the user to have to manually select 
'Settings->Save as default' in order to save settings.

Instead of requiring manual saving of settings I prefer the usability 
of KMail/KNode/KAddressBook/KOrganizer where the application 
automatically saves settings. 

Konqueror is also nice example. For bookmarks it has the automatic 
saving usability of KMail, and supports multiple processes modifying 
bookmarks.

Konqueror bookmarks are a good example of the type of problem KMail 
will have to deal with if multiple KMail processes are supported.

Konqueror bookmarks can be modified in any Konqueror process and those 
modifications will show up in other Konqueror processes that are 
running, and also in keditbookmarks. The IPC mechanism used to keep 
the bookmark data in sync is dcop, take a look at the keditbookmarks 
code to see the details.

KMail configuration data such as the network config is similiar to 
Konqueror bookmarks. If the network config data is changed in one 
KMail process then all other KMail processes should be notified of 
the change.

> > I'll assume that it's obvious that writing config data at app
> > exit is simple and explain why it's flexible and efficient.
>
> Yes, it's the most simple way. But it's IMO not the most sensible
> way (I don't agree with your arguments about flexibility and
> efficiency).

Sure everyone is entitled to their own opinion. I'm just trying to 
explain in an objective way why I personally prefer the 
componentization approach.

Ultimately the decision is not up to you, or I, it's up to the 
decision making group as a whole.

> BTW, I just want to mention two things:
>
> 1.) Storing config data in variables in the app and writing them
> back later violates compliance with the KIOSK mode. You should read
> Waldo's comments on kde-core-devel in the "Moving KPrefs from
> libkdepim to kdelibs" thread. At least our KMIdentity code breaks
> KIOSK. But since we also have a KMAccountManager I suspect that
> this code also breaks KIOSK. Let me quote one sentence you wrote
> and which very much smells like a KIOSK-incompatibility:

I read Waldo's comments. Yes, I think these variables are KIOSK 
incompatible. And I suspect these variables add unnecessary 
complexity. 

It might be a good idea to eliminate these variables, but doing so 
will not eliminate the problem of losing config changes.

The problem of losing config changes comes about because we're 
considering the case of multiple KMail processes running and:

1) It's desirable to have Konqueror bookmark semantics where a change 
to the bookmark data is sensed by all Konqueror processes. I would 
like similar semantics for KMail config data.

2) We don't want to sync the config data to disk whenever a config 
item is changed, because syncing the config data is slow.

3) It's not desirable to restrict syncing of config data to a single 
point in the program like when the config dialog is closed as that 
will reduce the flexibility of the KMail design. By making altering 
config data outside the config dialog more complicated.

> > Or rather we don't save it in the config file straight away, that
> > would require syncing which is slow, so we just update an object
> > that owns a network config variable.
>
> So much for efficiency aka deferred config writing to disk. 

I'm confident that a DCOP call to update the password config data will 
be much faster than syncing the config file to disk.

> It's a 
> nice idea but it's most likely incompatible with KIOSK.

I don't see why it's incompatible with KIOSK. The current KMail code 
will need to changed regardless for KIOSK mode to work.

> 2.) Since network configuration (accounts and transports) is used
> by a lot of applications (kmail, korn, kpilot, knode, etc.) I have
> proposed to move KMail's network configuration to kdelibs or
> kdebase and the other PIM developers are all for it. So at least
> the network configuration won't stay in KMail but will be moved to
> a central place (but this won't be the KMail server). So there
> won't be any problems with multiple instances of KMail all writing
> their version of the network config on program exit. The
> flexibility will be retained though.

Sounds cool.

So the advantage of the componentization approach is that it can be 
done in parallel with this change rather than being indefinitely 
delayed. 

And also if the componentization approach is done first then possibly 
the DCOP solution implemented could be used in kdelibs itself.

>   The same is true for the identities which will hopefully be
> shared with KNode, KAddressBook and kcmemail by KDE 3.2. The filter
> configuration is already only saved if the user select OK or Apply
> in the filter configuration dialog.

> And for the remaining options 
> saving them at program exit won't lead to loss of information.

Sorry that's not correct. The network config problem is just one 
instance of a general problem. Other examples are folder options, 
view menu options, and composer options.

All these options need to be handled with care, unconditionally 
writing these options at program exit can lead to information loss.

> So 
> this discussion is pretty much pointless.

It's possible this discussion is pointless. If you consider it 
pointless then that goes a long way towards making it pointless, but 
I hope others might find it valuable.

Don.
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]