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

List:       kde-usability
Subject:    Re: User Resources
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2005-08-22 16:58:49
Message-ID: 200508221059.03094.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 22 August 2005 10:26, Zak Jensen wrote:
> > if the power user can construct a special tool for this, then grabbing
> > the registered back ups would be a trivial task for them.
>
> They could, but then they would have to duplicate all of the code that
> was already created for the purpose. Why should they need to worry
> about parsing a standard registration file?

to begin with, it's not much code. and if it were to become so, that's why we 
have shared libraries: to hide complex things behind easy APIs. so even the 
worst case scenario has an immediate and obvious solution.

> It seems more wise to 
> define a standard location for the data when creating the standard.
> Complicated registration & configuration files could be added in
> addition to that standard location, but to perform the basic
> functionality--backing up my application data--I have 1 clean place to
> work from.

because a user still doesn't know that ~/.local/appdata/korganizer or whatever 
is their calendar information from Kontact. if we assume that all a user ever 
wants to do is backup and restore ALL application data, then yes, we could 
just ensure it's all smooshed into one place.

actually, we already do that and people get lost =)

no, even if all "files of type X" where X is in the set of {configuration, 
data, addons, ...} where in the same directory it's still not enough. there 
needs to be some documentation along with it and this documentation needs to 
be machine parsable (so we can build apps on it) and it needs to be easily 
added to / removed from at run time by new apps.

looking at the needs of kontact is a good place to start when looking for what 
is needed:

	o kmail
		o mail filters (config)
		o mail folders (data)
		o account setting (config)
		o other settings (config)
	o korganizer
		o calendars (kresources, which resolve to data)
		o todo's (ditto)
		o configuration (config)
	o contacts
		o local address books (data)
		o configuration (config)
	o notes
		o notes (data)
	o feeds
		o configuration

the user ought to be able to just say "back up my groupware" and have all the 
above taken care of. they should also be able to say "restore my email" and 
have just kmail's data be restored. it should be a matter of selecting things 
from a list or even selecting this from the application itself ..

this should also work for non-KDE applications so that we can have one means 
of describing these things as opposed to N different ones. our implementation 
may be optimized for KDE, but it can't be specific to it.

> > and the app would be running to ensure that this happens. relying on
> > "cron" or some other system specific facility isn't really an option.
> > (portability, simplicity)
>
> Maybe KCron or KAlarm or something of that nature then? Windows and
> OSX both have their own ways to implement recurring actions. Let me
> clarify: "My idea was to use a backup program which reads a
> configuration file, and is run periodically by the underlying
> operating system. A front-end would be desinged that allows users to
> create and maintain the configuration files, which include those of
> the backup system, and the underlying scheduling system".

we could certainly build on kalarm and make that a dependency, since that is 
something within our control. at the end of the day we'd need to rely on some 
mechanism that ships with KDE and runs continuously. the rest are 
implementation details =)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


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