[kdepim-users] New computer

[ianseeks]

On Sunday 15 August 2010 18:04:57 Kevin Krammer wrote:
> On Sunday, 2010-08-15, ianseeks wrote:
> > On Sunday 15 August 2010 17:11:23 Kevin Krammer wrote:
> > > On Sunday, 2010-08-15, ianseeks wrote:
> > > > On Sunday 15 August 2010 12:10:31 Ingo Klöcker wrote:
> > > > > On Sunday 15 August 2010, ianseeks wrote:
> > > [snip]
> > > 
> > > > > > and the home directory is littered with "." files.
> > > > > 
> > > > > Historical reasons. In the stone age of Unix user specific
> > > > > configuration was stored directly in '.' files in the home
> > > > > directory.
> > > > 
> > > > I know, but thats not a reason for lack of improvement.
> > > 
> > > True.
> > > Given the time most of these applications have been around, new
> > > standard locations like specified in the XDG base dir spec are
> > > relatively new.
> > 
> > Hopefully this will come online soon
> 
> Not sure what you mean, the XDG base dir spec is available for quite some
> time already. It is new relatively speaking compared to the age of a lot
> of software that traditionally stored config into $HOME.
> Some of the respective development teams might not even be aware of the
> spec or ignore it if the don't consider their applications to be "desktop"
> apps.
Perhaps i need to install 11.3 from scratch and rebuild my home dir. Maybe 
most of the "." files making a mess there are hang overs from upgrading from 
previous releases.
> > > >  >Consequently, there's no way on earth to
> > > >  >
> > > > > make it user friendly by creating "a simple template structure that
> > > > > all KDE programs should follow". (BTW, it wouldn't help a bit if
> > > > > just KDE applications follow it.)
> > > > 
> > > > If they don't follow it, they should not be allowed to known as a
> > > > true KDE application and get stuck in the playground.,
> > > 
> > > Ingo was not referring to KDE applications not following a certain
> > > pattern, he was referring to non-KDE applications.
> > 
> > Non-KDE apps can whistle and sort themselves out.
> 
> Sure, just clarifying the misunderstanding between Ingo's statement and
> your reply.
> 
> > > > > > I understand that Akonadi is not a KDE component but as it is
> > > > > > being integrated into main KDE programs and is now by
> > > > > > association, an absolute KDE app dependency as certain apps will
> > > > > > not run without it. In my opinion, it should follow the KDE
> > > > > > config and data structures.
> > > > > 
> > > > > I'm sorry, but that's not how it works. Akonadi aims at being used
> > > > > not only by KDE but also by Gnome, OpenOffice, Thunderbird,
> > > > > Firefox, etc. I guess this makes clear why putting Akonadi's
> > > > > settings and data below ~/.kde makes absolutely no sense.
> > 
> > True, i realised that. I was thinking that if all KDE progs had separate
> > Akonadi databases, the databases could still be put under the relevant
> > .kde structure. Gnome apps would put them under the Gnome structures
> > etc, but i am assuming that each app would have a way to configure where
> > its data is located.
> 
> Common misunderstanding of Akonadi's purpose and Akonadi's database usage
> :)
I thought i might be off but but its clearer now. 
> The core idea of Akonadi is to have centralized access to data of the same
> type, e.g. one place to go to for contacts or emails.
> So having one Akonadi per application would not make any sense at all,
> applications would be back to where they have been (e.g. file locking
> issues, etc.)
> 
> The database used by Akonadi is only occasionally used to store data (as in
> contacts or emails), i.e. only when the actual storage is unreachable (e.g.
> no network connection to a groupware server).
Sounds just like the electronic journaling system we had on our branch client 
machines, central file directly updated on branch server when online. local 
file on workstation when offline with auto-updating when back on line - gawd 
memories of that system go back to MSDOS days.... took a long long time to get 
100% stable

> Its main purpose is to store relational information, e.g. where an item
> comes from, what MIME type it has, etc.
> 
> Duplicating this information over and over again into separate databases
> for each application again makes little sense.
> 
> > > > Question:  does each application that uses Akonadi have its own
> > > > settings and data or do all apps share one database and settings
> > > > database , a bit like the Registry on that other OS?
> > > 
> > > That depends on what level you look at it.
> > > Akonadi is neither a configuration database like the Windows registry
> > > nor a general dumping ground for application data.
> > 
> > I was looking at it from the data level i.e. if all KDE apps that used
> > Akonadi would their data be held in separate database files i.e.
> > kmail.db, contacts.db, calendar.db or one huge database file.
> 
> No, see above.
> Data is not stored in db files, but on servers or appropriate local files
> or directoreis (e.g. vcf for contacts, maildir for mails, etc)
> 
> > > Depending on an applications purpose and functionality it could not
> > > require any configuration on its own and just work with data provided
> > > through Akonadi. But it is also possible, or actually quite likely,
> > > that an application will have some configuration items that are
> > > specific to its purpose, e.g. which of its toolbars to show.
> > 
> > E.g. kmails setting for connecting to the ISPs etc, would they be in a
> > ".file" or database
> 
> These settings are in the configuration file of the respective Akonadi
> resource (backend connector).
> 
> Cheers,
> Kevin
Thanks for the clarification, the mud is a little clearer now.

regards

Ian
_______________________________________________
KDE PIM users mailing list
kdepim-users at kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users