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. Ahhh 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 [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/cheese-list ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Martin Owens schrieb: Dear Felix, Ahhh 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! Calm down dear, it's only a discussion. I am calm =) Sorry if it looked like I'm agitated or something ^^ Now I think your idea is not bad at all, because we have a quite nice folder structure already (Documents, Pictures, Videos and so on). But they must be used! Correct me if I'm wrong, but FSpot makes its own directory (/home/foo/Photos) for the pictures you want to copy to picture location (you can select this option when importing pictures to fspot). I still see some issues (like a unified way to save emails, not that if I first use Thunderbird my emails are stored like foo.mail and with Evolution they are stored like 080916_foo.evomail or similar) but issues are here to resolve and as you pointed out already: this is a discussion, so lets discuss :) Martin, are you familiar with Cosimo Cecchi's Summer of Code project? (http://code.google.com/soc/2008/gnome/appinfo.html?csaid=15C2B5BC19A9276A) Probably a integration of his media manager into nautilus would solve some of your problems? cheers felix ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Dear Felix, Ahhh 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! Calm down dear, it's only a discussion. 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... I don't think it would be that much of a 'tsunarmi' not only would defaults be selected in a way which would make them structured and shared; but they would be configurable (even to the point of hiding) and wouldn't exist until you needed them anyway. The idea is nice, but not for every program! Why should I want to access the emails directly? Why wouldn't you want to? 1) Backup your emails without special software, 2) Be tied to a specific program for the rest of your life with special syncing software. 3) Unable to index emails without special indexing software. 4) Be able to search for emails without a searcher that integrates with said indexing software 5) Be able to input and export to and from other services and devices without special software. In fact one of the themes of the above is that for every innovation you need to have special software which interacts with the application APIs or hidden proprietary formatted configuration files in order to do anything interesting. It's a lot of wasted work which only comes about because developers think it's nice to want to hide their user's data. 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! So be it, no one said these folders couldn't be hidden in a teletubby distro for those who are weak of heart. As far as a step in the wrong direction I think not: the underlying technical principles set forth in my previous emails would be valuable, if employed in an integrated manner. they would allow people to move from/to gnome/kde/xfce without having to sync data, it would allow programmers far more stability and confidence in how to access various types of data, creating a platform for more interesting ideas to be tried out. Oh and most people end up creating a backgrounds folder anyway. Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Hi Felix, Now I think your idea is not bad at all, because we have a quite nice folder structure already (Documents, Pictures, Videos and so on). But they must be used! Correct me if I'm wrong, but FSpot makes its own directory (/home/foo/Photos) for the pictures you want to copy to picture location (you can select this option when importing pictures to fspot). Yes that is the case, the way these directories are configured is that there is a config file which lists each one. this allows for folders in different languages to be used correctly by programs without having to have that foreign language support built in (without breaking horribly). Getting folders used is a matter of project preference, although support for the ideas from other developers would help push standards too. I still see some issues (like a unified way to save emails, not that if I first use Thunderbird my emails are stored like foo.mail and with Evolution they are stored like 080916_foo.evomail or similar) but issues are here to resolve and as you pointed out already: this is a discussion, so lets discuss :) The file names them selves might not be such a problem so long as the structure is well defined. Making sure the folder structures in evolution correspond to the folders in the file system would be a first step. This may either be done through convention or by configuration (such as a more detailed XDS) The file formats and the mime-type would be the most important aspects after structure. E.g ~/Email/Personal Account/Inbox Martin, are you familiar with Cosimo Cecchi's Summer of Code project? (http://code.google.com/soc/2008/gnome/appinfo.html?csaid=15C2B5BC19A9276A) It's a very interesting project, it actually seems more radical than my ideas but certainly is along the same lines. Having an index based file chooser is a very useful feature. Probably a integration of his media manager into nautilus would solve some of your problems? Although the main aspects of being able to run your files through any application outside of gnome is still very attractive. ergo: ssh from your laptop to your computer, your looking for a contact in your evolution account. You have the command line. P.S. I've taken cheese mailing list off the reply, don't want to flood their list. Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Hi, first, let me tell you I perfectly agree with you that user data should be easily accessible to users. It's their data after all. Now I want to shade this a bit for what is usually called PIM data. imho, users (I mean normal non-geeky users) often only know about one way of getting to their data and can only handle few at a time. This is really important wrt to what you said about mails. Somebody replied to this thread qualifying what would be the direct (brutal) application of your proposal as a tsunami of data and I can only agree with that. This would be a poor user experience really :) About standards, evolution actually uses standards to store data, mbox for mails, ics/vcard for addressbook, events memos. It can also export all of these data from their hidden store to another standard format. Even nicer, it has a backup plugin that saves all this and configured accounts to a tarball that you can save anywhere you want. Personnaly I've had harder times getting my data out of thunderbird last time I tried (which was probably ~1.0). Now obviously all programs probably won't be able to deal with evolution's backup tarball (but most probably can with individual exports) but that's probably because nobody even thought about getting started on standardizing this kind of stuff before. -- Gilles Dartiguelongue [EMAIL PROTECTED] signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Hi Gilles, first, let me tell you I perfectly agree with you that user data should be easily accessible to users. It's their data after all. It's not just abut accessibility in your currently working computer at this point in time. It's also about visibility, compatibility with alternative and future programs, the ability to use these files in interesting way. Do we have a program that can give you real time reports on your emails? do we have innovation in data processing? I beleive hiding the data has lead everyone down the garden path, restricting compatibility, reducing the drive for standardisation and ensuring programmers have lots of work to do in the import and export plug-ins market. Now I want to shade this a bit for what is usually called PIM data. imho, users (I mean normal non-geeky users) often only know about one way of getting to their data and can only handle few at a time. Dealing directly with how the user interfaces is an important question, but I believe we must enable as many routes to use our data effectively with the way we structure our output. For instance I don't believe someone will check their emails in nautilus. But could they do a search or open those self same emails in kmail without syncing and api bridging crutches? Could they access their email in a command line tool? is there a way to send a message in a business account on evolution as an attachment in your gmail account? This is really important wrt to what you said about mails. Somebody replied to this thread qualifying what would be the direct (brutal) application of your proposal as a tsunami of data and I can only agree with that. This would be a poor user experience really :) Well only if the emails were all pushed into their face, say if we store them all in ~/, I'm not advocating bad design. Picking out the ideal structure for where emails go which is out of the way but still available is important. The suggestions I've given already make it clear that the system is just as important as the principle to make sure we don't introduce new problems. About standards, evolution actually uses standards to store data, mbox for mails, ics/vcard for addressbook, events memos. this is good, if EDS is already using these files then it's not much of a change to make it configurable and/or based on XDS directories (which distro's could then configure) giving users, distributors and other programmers ways to find and control data output in what ever way they feel their target users would like. It can also export all of these data from their hidden store to another standard format. Even nicer, it has a backup plugin that saves all this and configured accounts to a tarball that you can save anywhere you want. Personnaly I've had harder times getting my data out of thunderbird last time I tried (which was probably ~1.0). Lots of exports are band-aids, some exports are genuinely useful such as svg to pdf, going from editable design stage to print ready production. others are for compatibility or for backing things up. Exporting an email to a processed thread file would make sense I think. Exporting it to an email backup file seems like it's trying to get around the limitations of the user data storage, because if normal backup solutions can't back your emails up without making special exceptions to decided what is data and what is configuration for every app it's not doing something right. Now obviously all programs probably won't be able to deal with evolution's backup tarball (but most probably can with individual exports) but that's probably because nobody even thought about getting started on standardizing this kind of stuff before. If you made a backup using a standard file backup utility when using the proposed ideas; you would be able to recover the emails in the right directories ready for use, even if during the time you had moved applications or even platforms. In fact there would be no thought needed from the user, it would be a simple matter of getting the files in the right places. As for opensync, could you imagine if they could eliminate all those custom end point plugins for each and every application? Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
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 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Hi, I think it would be important to distinguish between a local cache of a remote IMAP or CalDAV folder (i.e. Configuration) vs. local mail folders, calendars, contact lists, etc. (Data). I agree, I regretted not making a note about cache data. Caches are temporary stores, if it makes sense to export them to a more permanent states then that would be where they'd translate into user data. As an example, pidgin's user lists and profile images are cache, unless the contact is tied to a standard address book system where the profile image could be stored in the right place it's not permanent and is more of a state of the application. Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Shouldn't the Telepathy framework be considered for storing account settings? Remco ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Nice thoughts, really nice thoughts! But I have to defend cheese! You're right, storing the pictures in a hidden directory is not that good! The maintainer of cheese, daniel siegel implemented it this way, because he thought storing all these random-crazy-looking-pictures taken with cheese in the photo directory makes more than a mess! Anyway, we have changed that already in the latest version (which will be released with gnome 2.24 on Sept. 24)! Now the pictures and videos are stored either in a user-defined path (at the moment its only a gconf option, but it could be part of a preferences dialog too in future...) or in the standard xdg folder [1], for example /home/foo/Videos/Webcam (if the gconf option is not set)! So, try out the new cheese and tell us if you like it ;) Best Regards, Felix Kaser [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html Martin Owens schrieb: Dear Ubuntu and Evolution Developers, I'm sending this email to the gnome evolution hackers list to see what their thoughts are. I have noticed a really odd disconnect in gnu/linux with user data which has me a little worried. Some user data is hidden from users in configuration directories. Technically configuration directories denoted by being hidden (suffexed with a '.') are there to hold collections of configuration files for the applications which they serve. But there are plenty of programs using these directories to store the data results as well as configuration. For consideration I present Cheese, a very nice tool for using web-cams to take photos with weird disfiguring effects. The problem as I see it is that Cheese stores each of the photos in it's ~/.cheese directory which makes them hidden from the user. Instead I propose that Cheese use a standard directory (possibly configurable) such as ~/Photographs/Cheese or ~/Documents/Cheese which is accessible to user browsing. Cheese is an excellent example of making user data more accessible to casual file browsing which is not just limited to jpeg images but could just as easily apply to the way Evolution stores emails, addresses, contacts and so on. In these instances the data is always bound up in evolution specific formats inaccessible to casual browsing as well as casual integration (without delving into the EDS API) I'd like data to be available to send in an email, or browse in nautilus (or on a command line) I'd like to be able to open the same jpeg in image viewer and gimp, not just in what ever created or generated them. I'd like to be able to open addresses and copy an event file to my thumb drive. Wouldn't it be good to backup all your files without configs and be sure your not missing emails or bookmarks? In fact the methods we use to store data seems to be along the same lines that certain Windows and Mac programs use to obfuscate and hide data in order to lock users into their products. Do we really need to do this on our gnu/linux systems? Should we instead intend user data to be converted with plugins and export features in every application because of their hidden default outputs? This issue may be interesting to the FDO (freedesktop.org) crowd. It is a very heavy topic that will probably get me a little flaming because it goes against what is currently best practice. Best Regards, Martin Owens ___ Cheese-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/cheese-list ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
On 13/09/08 11:48, Martin Owens wrote: Technically configuration directories denoted by being hidden (suffexed with a '.') are there to hold collections of configuration files for the applications which they serve. But there are plenty of programs using these directories to store the data results as well as configuration. 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. I wonder how would you differentiate between data and configuration if you were to write a specification for this? 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. The account information is stored in an XML file which mixes Pidgin-specific data with user IRC account data. 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? -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Am Freitag, den 12.09.2008, 23:48 -0400 schrieb Martin Owens: For consideration I present Cheese, a very nice tool for using web-cams to take photos with weird disfiguring effects. The problem as I see it is that Cheese stores each of the photos in it's ~/.cheese directory which makes them hidden from the user. Instead I propose that Cheese use a standard directory (possibly configurable) such as ~/Photographs/Cheese or ~/Documents/Cheese which is accessible to user browsing. Just FYI, this has been fixed three months ago: http://bugzilla.gnome.org/show_bug.cgi?id=509475 andre -- mailto:[EMAIL PROTECTED] | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Configuration masquerading Data
Dear Ubuntu and Evolution Developers, I'm sending this email to the gnome evolution hackers list to see what their thoughts are. I have noticed a really odd disconnect in gnu/linux with user data which has me a little worried. Some user data is hidden from users in configuration directories. Technically configuration directories denoted by being hidden (suffexed with a '.') are there to hold collections of configuration files for the applications which they serve. But there are plenty of programs using these directories to store the data results as well as configuration. For consideration I present Cheese, a very nice tool for using web-cams to take photos with weird disfiguring effects. The problem as I see it is that Cheese stores each of the photos in it's ~/.cheese directory which makes them hidden from the user. Instead I propose that Cheese use a standard directory (possibly configurable) such as ~/Photographs/Cheese or ~/Documents/Cheese which is accessible to user browsing. Cheese is an excellent example of making user data more accessible to casual file browsing which is not just limited to jpeg images but could just as easily apply to the way Evolution stores emails, addresses, contacts and so on. In these instances the data is always bound up in evolution specific formats inaccessible to casual browsing as well as casual integration (without delving into the EDS API) I'd like data to be available to send in an email, or browse in nautilus (or on a command line) I'd like to be able to open the same jpeg in image viewer and gimp, not just in what ever created or generated them. I'd like to be able to open addresses and copy an event file to my thumb drive. Wouldn't it be good to backup all your files without configs and be sure your not missing emails or bookmarks? In fact the methods we use to store data seems to be along the same lines that certain Windows and Mac programs use to obfuscate and hide data in order to lock users into their products. Do we really need to do this on our gnu/linux systems? Should we instead intend user data to be converted with plugins and export features in every application because of their hidden default outputs? This issue may be interesting to the FDO (freedesktop.org) crowd. It is a very heavy topic that will probably get me a little flaming because it goes against what is currently best practice. Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
