Configuration masquerading Data

Martin Owens doctormo at
Thu Sep 18 00:53:54 UTC 2008

> I think this idea is extremely valuable and merits robust discussion to
> discover ways to encourage application developers to incorporate this
> way of approaching data storage.

Thank you, I'm not always as coherent as I'd like when I describe my
ideas and knowing it made sense to you gives me confidence in
presenting it as a discussion at UDS in December.

> I wonder how would you differentiate between data and configuration if
> you were to write a specification for this?

There is a logic between the two can be broken down into the following

Configuration - Data which changes the state and logic of a
computation, key selection of the flow of an application or execution
which are not involved in the input or output data directly.
User Data - Data which is directly the input or output results for any
computation or use.

> Consider for example Pidgin, which stores its account data within a
> ".purple" directory. The same tree also contains logs for each of the
> discussions, icons, application preferences and miscellaneous other files.

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

> 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

More information about the Ubuntu-devel-discuss mailing list