[Kde-pim] configuration in akonadi-next

[Sandro Knauß]

Hey,
 
> * trivial text files (storing binary data structures or strings generated
> from internal run-time data structures are not that)
> * text files which the user knows the location of, the structure of and the
> allowed contents of
> 
> The latter can be resolved by documentation for people willing to put in the
> time.

Yes but there are people you are wiling to put time into it. And the current 
situation with nearly no documtation, makes it more difficult to use the 
files. This is something we can improve in any case :)

> But who is going to put in that sort of time to deal with Kontact
> configuration files? Users generally require tools that make short work of
> tasks in humane ways. It is why we create GUIs in the first place.

Users use the application settings to interact with the configuration in first 
place. You normally interact only with the files if
* something is broken
* not accessable from the setting dialogs
* you want to write a bugreport
* you are admin that wants to preset some configs (/etc/kde4/ )

I would say, that are only advanced users. And actually the only interact with 
the files because our first tool (setting dialog) failed. We should be very 
sensitive in developing new tools that also can fail. In the end we want to 
have a backup stragety, if these new tools fail...

> Kontact users would be much, much better serviced by a set of tools that
> manage Kontact and Akonadi's (necessarily!) complex configuration data.

Well we now have a very completly complex configuration data - for sure. But 
IMO that was a grown configuration. And I would first start in looking if we 
can make the configuration simple before starting developing, we need new 
tools.

> I've already demonstrated in previous emails how the data in Kontact /
> Akonadi configuration files are entirely opaque to just about everyone who
> isn't a Kontact / Akonadi developer. Instead of saying "It is so", please
> address that.

The point i see here is, that configuration options are introduced without 
make them readable for humans (aka strigify/serialize). But this problem you 
don't solve with binay config files. See akonadi - the collection attributes 
are normally readable for humans but is you look at blockalarmsattribute there 
the boolean value is written directily to the string -> not human readable 
string. And in my understanding akonadiconsole is a specialized tool, that 
should help me in interacting with akonadi data. Binary config file do not 
prevent us that we need to translate a value to something human readable.

In the end it doesn't matter, that file format we choose, we need to strigify 
the output if the output should be read by a human. If we store binary config 
files we have to create such output on the fly with text config files we 
output this directly we interaction with the program/settings dialog.
 
> Well, a hex editor is not a "special" tool. but if there is no real world,
> actual benefit derived in actual practice, it doesn't matter (theory is
> worth zero). so how many of our users edit their config files with a text
> editor? for those that do so: why do they do so? is that their first
> choice, or would they be better served by other means?

I interact with the config files if I develop - disable the KDE sound for all 
users in, set up the standard akonadi backend to mysql... 

But also in daily life I look at config files, if someone asks me how I did 
setup such and such programm. And open a texteditor copy some lines and send 
them via mail/chat is a very easy . Okay I could also make screenshots. But 
what I really do not want is to use a specialize tool for every programm I use 
to get readable config files. And please keep in mind: We are talking about 
the 2% of the users, that have to deal with problems, because other tools 
(setting dialog etc.) have failed. 
All my experience with programms using binary config files: if something is 
broken, than I have to delete everything and I have no way to diff.

> To be honest with you, I'm not overly concerned about text vs binary config
> file formats. It's a somewhat minor issue. I am, however, concerned about
> the project's ability to make decisions based on actual needs driven by
> actual user practice, and that's a way I'm trying (evidently without
> success ;) to encourage people to approach these kinds of topics.

+1 the currect situation is a completly mess - cause every programm saves 
their configfiles at other places. And not every config parameter is readable 
for humans and the parameters are hardy documented... But I don't see the 
advatage in setting up a new config format. Only it is a new start, so we can 
cleanup the current config files, but this we could also do without changing 
the format.

Instead of talking about the format, we should start talking about, what part 
of kdepim needs what config. And how we should structure them in a 
userfriendly way. After that we could think about the format.

Regads,

samdro
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/