Re: [Evolution-hackers] Configuration masquerading Data

[Felix Kaser <f kaser gmx net>]

> 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
>
>