Re: [Evolution-hackers] XDG Base Directories
Hey Matthew, I welcome the move to XDG at last but... On Sun, 2010-06-06 at 12:34 -0400, Matthew Barnes wrote: .local/ +-- share/ +-- evolution/ +-- addressbook/ | +-- local-backend-files +-- calendar/ | +-- local-backend-files +-- mail/ | +-- local-backend-files +-- memos/ | +-- local-backend-files +-- tasks/ | +-- local-backend-files +-- camel-cert.db +-- cert8.db +-- cert9.db +-- key3.db +-- key4.db +-- mapi-profiles.ldb +-- secmod.db Comments: * Cached Camel provider data moves to ~/.cache/evolution/mail. This includes folders.db. Files for local accounts will be divided up: index files for searching would go in ~/.cache, whereas actual mail content (mbox/Maildir/etc.) would go in ~/.local. Need to think on that some more. You do know that ~/.local is for user application data and not application user data? Yes they sound almost like the same thing, but there is a very big difference between firefox plugins/evolution filters and emails/calendar events. Because hiding user data is cool and making backups impossible is awesome. If you're planning on separating out the indexing (a good move) then why not just park emails in ~/Documents/Email in a list of maildirs? Martin, ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories
On Sat, 2010-10-16 at 11:49 -0400, Martin Owens wrote: * Cached Camel provider data moves to ~/.cache/evolution/mail. This includes folders.db. Files for local accounts will be divided up: index files for searching would go in ~/.cache, whereas actual mail content (mbox/Maildir/etc.) would go in ~/.local. Need to think on that some more. You do know that ~/.local is for user application data and not application user data? Yes they sound almost like the same thing, but there is a very big difference between firefox plugins/evolution filters and emails/calendar events. Because hiding user data is cool and making backups impossible is awesome. If you're planning on separating out the indexing (a good move) then why not just park emails in ~/Documents/Email in a list of maildirs? My examples above were mistaken. I was referring to account types that deliver mail to the On This Computer store such as POP. How and where those mails get stored is up to Evolution. You can still set up ~/Documents/Email as the root of a maildir tree and point Evolution at it. The data there won't be moved. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories
Le dimanche 06 juin 2010 à 12:34 -0400, Matthew Barnes a écrit : Once thing I'd like to get done before Evolution 3.0 is dismantling ~/.evolution and moving user-specific data to relocatable XDG base directories [1]. I have an initial proposal of what should go where. Migration should just be a series of straight-forward move commands, plus a few subtle renames. Not sure yet if I'm gonna code this all up in C or just write a shell script to invoke. I'd like to get this in before I get much further on my gsettings branch, as I'll be changing how we store account data (no more XML blobs!) and our directory layout closely ties into it. See additional comments below. [...] Comments: * ~/.evolution/cache moves to ~/.cache/evolution, with one exception: just use /tmp for stuff that normally goes in ~/.evolution/cache/tmp. * Cached Camel provider data moves to ~/.cache/evolution/mail. This includes folders.db. Files for local accounts will be divided up: index files for searching would go in ~/.cache, whereas actual mail content (mbox/Maildir/etc.) would go in ~/.local. Need to think on that some more. * ~/.cache/evolution/http will eventually die when we move to WebKit, since it uses (or will soon use) its own disk cache. * ~/.evolution/$COMP/local moves to ~/.local/share/evolution/$COMP. * I debated whether certificate and profile databases are data files or configuration files. I decided data files, based on my rule of thumb that configuration files should be human-readable. Any comments or concerns? Have I missed anything? sounds good. Id like to mention again that it would be nice if evolution could take into account system certificates as a basis for user trust settings in certificate signatures, etc. I don't know if nss is just getting in the way for this, but evolution and firefox are currently the two apps that I use most often that don't actually obey my system configuration by default. -- Gilles Dartiguelongue gilles.dartiguelon...@esiee.org ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote: For those following the master branch of git, that means that with any luck your ~/.evolution directory will soon be gone and you'll have far more control over where Evolution writes files. Hi, does this mean that one would be able to keep .evolution folder as is, with some XDG foo? You know, sometimes is useful to run 2.30.x while developing 2.31.x on the same machine, where your change makes it impossible. But if it's possible, do you know the XDG foo to achieve it? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Sun, 2010-07-25 at 19:23 -0400, Matthew Barnes wrote: On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote: I now have all the migration routines written and I'm fairly happy with them. A few more cases to test and I think I may commit this over the weekend. I decided to defer this until at least Tuesday, so that those developers who aren't weekend workaholics like me still have some advance warning when they fire up their email on Monday morning. The base directory transition is now in master. Once again, please be mindful not to mix versions of Evolution and the addressbook and calendar factory daemons. The migration should be nearly instantaneous. It's just a series of directory renames and a few config file renames. Each of the three binaries will print equivalent UNIX shell commands (mv and rmdir) to the terminal along with any errors encountered to help track migration progress. This output is valuable for debugging migration issues. Please let me know immediately if you encounter any regressions. If there -are- regressions I expect they will be caused by Evolution not finding some data, either because the data failed to migrate or because Evolution is still looking for migrated data in its old home. In either case the data should still be present on your hard disk. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote: I now have all the migration routines written and I'm fairly happy with them. A few more cases to test and I think I may commit this over the weekend. I decided to defer this until at least Tuesday, so that those developers who aren't weekend workaholics like me still have some advance warning when they fire up their email on Monday morning. Also, I plan to merge one of Srini's branches tonight with some exciting new features for Express mode. That's gonna kick up some dust that will need to settle before I drop the next bombshell. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Sat, 2010-07-24 at 07:48 +0200, Yves-Alexis Perez wrote: An an evolution user and a packager, is this really a good idea? Shouldn't it be safer to keep it “as a backup” but mark it as already migrated. This way, another attempt can be tried should the first one fail, and we don't touch user valuable data. Are you suggesting we copy the data instead of moving it? That could be a -lot- of data. It also runs a higher risk of failure since the user's hard drive may not have enough free space for a copy. The migration at present is just a scripted sequence of rename() and rmdir() commands. The problem is we have three binaries writing data there. Two of those have no user interface, and may start long before you launch Evolution itself. So the migration needs to happen in phases, and I don't see a way to warn the user ahead of time. By the time you start Evolution, the data may already be 2/3 migrated by the D-Bus services. That said, I'm open to ideas for making the process safer. Especially for the case where the user tries to downgrade and then panics because Evolution suddenly can't find his data. Should Evolution present a big scary warning at startup if it sees (from GConf) that a later version was previously run? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers