Re: [Evolution-hackers] Configuration masquerading Data





Examples:
 - Pidgin
 * Configuration - Settings for which services to connect to, what
skins to use and what plugins to use.
 * Data - Text entered at the keyboard, text received over the
service, files received or sent over the service, chat logs.

 - Gnome Background Settings
 * Configuration - which background is selected, which backgrounds are
available, how a background is to be presented.
 * Data - Background image files

 - Evolution Email Application
 * Configuration - which services to connect to, which plugins to use,
syncing rates, display preferences.
 * Data - Email messages recieved, contact data, calendar event, note
text, text typed in, files sent as attachments.

Aaaaahhh wait! It's nice you separated data and configuration, but to be honest: I really don't want my home directory to be flooded with data I don't even want do see outside the application! I don't want to have a folder "background images" in my home where the background images are, I don't want to have a "evolution emails" folder where I can get to my emails without opening Evolution itself! I don't think I'm alone with this thought...think of all the "non-power-user", for them it would be a tsunami of data they cannot handle...

The idea is nice, but not for every program! Why should I want to access the emails directly? I can use Evolution for that, its nicer and a lot more user friendly then the file explorer is! I think this is a big step in the wrong direction, you would like to use the email application just to make the connection and download the mails! That reminds me of the old telnet email clients - my uncle still uses one of them, because he's familiar with that - but we have really powerful applications now, we should use them!


What I'm asking is, at which point do you think the line between
application data and user data needs to be drawn, or do you think that a
best practice approach might incorporate the idea that if your
application stores information that is useful to another application, it
should be stored in a non-configuration location?

There is a further separation at the configuration level which must be
accounted for. Sercive configuration often involves standard protocols
which multiple different apps for different reasons could use the same
configurations for. This isn't to be confused with user data though. A
directory for ~/.services/email/accounts.xml would be a way of
standardising the service/protocol level configuration.

User data though needs to be stored in ways which users have control
over directly. The cheese project recognised that keeping photos out
of the home directory browsing space was a bug and that hiding user
data is not a desirable quality when you want flexibility and user
control. The fact that other applications could use this data is a
useful side effect too.

For instance using XSD directories cheese has allowed F-Spot to be
made to import photos from the XDS directory, grabbing cheese photos
and then allowing the user to export them to flikr or what ever the
user wants. This provides a level of context to a users data and power
to the user.

The XSD directories idea is a very powerful one which should be
considered for more user data than it is currently.

Another aspect is making sure that each elemental datum has a standard
format which we can use to allow the user control of. For instance an
image can be saved as a png file, An email message can be saved as an
eml/message file and a bookmark can be saved as a link file. but not
all of the available formats have been agreed upon, standardised or
even meet all of the feature requirements of the applications
involved. For instance vcards are nice, but I can't see EDS using them
as a data store since it's not a very normalised format.

I should also make a note that just because the data is stored in
files in some of these examples doesn't mean you are forced to forgo
the use of an index. The mechanism of recording your email messages in
a sqlight db file which may or may not be specific to the application
is not in question.

Let me know if I've managed to explain my ideas on how we can
differentiate user data from configuration data. I'd be interested in
cases which break my logic.

Best Regards, Martin Owens
_______________________________________________
Cheese-list mailing list
Cheese-list gnome org
http://mail.gnome.org/mailman/listinfo/cheese-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]