> 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 definitions: 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. 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. > 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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
