Re: [Evolution-hackers] Rethinking account management
>
> (I'm leaning away from having URI keys, favoring instead URI components
> as separate keys from which a complete URI string can be formed.)
As someone who's used ESource in the past .. I always found the old
way of doing it oh-so-confusing. I even added the following code to
dates:
/*
* Also ensure that the sources contained within this
* group have an appropriate uri setup. Removing the
* absolute uri in favour of a relative one.
*/
source_list = e_source_group_peek_sources (group);
for (GSList *source_list_it = source_list;
source_list_it != NULL;
source_list_it = g_slist_next
(source_list_it))
{
ESource *source = (ESource
*)source_list_it->data;
if (g_str_equal (e_source_peek_relative_uri
(source), ""))
{
const gchar *uri =
e_source_peek_absolute_uri (source);
gchar *path = g_filename_from_uri (uri,
NULL, NULL);
gchar *base_name = g_path_get_basename
(path);
e_source_set_absolute_uri (source,
NULL);
e_source_set_relative_uri (source,
base_name);
g_free (base_name);
g_free (path);
}
}
g_free (path);
g_free (new_uri);
Cheers,
Rob
___
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] Getting rid of shipped libdb
On Tue, 2008-10-07 at 18:14 +0100, Michael Meeks wrote:
> Hi Rob,
>
> On Tue, 2008-10-07 at 16:49 +0100, Rob Bradford wrote:
> > Hhh. But. The use case you outlined directly above about where this goes
> > wrong also applies here: "Oh. You ran e-d-s on a machine with a version
> > that migrates it to Some Other Format (tm). You then add some contacts
> > which go into the new format. Then you go back to your old machine.
> > *Boing*. Same problem, your new contacts are missing :-("
>
> Yes true - but at least, this is a once-and-for-all fix ;-) and of
> course there is no reason to say that we can't sync them to the old db
> format too for a while.
Ack.
> > I would expect migrating from one version of GNOME and then back again
> > is probably pretty problematic anyway...ultimately I think you need to
> > draw the line at some point.
>
> True - but having a problem at -every- version point, and across ~every
> distribution such that "I used SUSE and now I can't switch back to
> FooBaked Linux !" is not good ;-)
Ack. Although i'd have thought we'd have seen more bugs relating to
people upgrading...through several generations e.g. Ubuntu.
> > Somewhat orthogonally: Also, I wonder on the performance impact of the
> > flat-file approach wrt, modification / deletion when dealing with ~1k
> > contacts.
>
> Fast enough I guess; I have ~3k real-life contacts, and that is ~1.5Mb
> of addressbook.db [ which seems pretty much a flat vcard file when you
> read it ;-].
Okay.
>
> It seems my pmap is struggling to work ATM, but it'd be interesting to
> know how much of addressbook.db is 'hot' in e-d-s anyway.
For queries that Evolution does the summary is used quite extensively.
The summary is an in-memory cache which is then serialised out to disk.
Searching is therefore an O(n) strcmp exercise. For just the reading
case i'd expect to find that the database is not very hot since the
summary should help with a lot of the searching. From the summary you'd
get the UID you were lookibg for and then can do an efficient (hashed)
UID based lookup to find the VCARD.
I did some work to replace this with a bdb index:
http://bit.ly/1GrCPL
This had the benefit of being more flexible about the fields you could
index and you get some better performance for queries since you can
exploit the hash to help you find what you're looking for. (As an aside
there is also the memory impact of not having to have the summary in
memory perpetually.)
Cheerio,
Rob
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Tue, 2008-10-07 at 14:22 +0100, Michael Meeks wrote:
> On Mon, 2008-10-06 at 18:35 +0100, Rob Bradford wrote:
> > Okay. Have you got these details? It would be good to see which of those
> > still apply, etc..
>
> Sure - the original rational here (AFAIR) is quite simple.
>
> If you share the same .evolution across multiple machines, and the
> version of libstupid is different: bad luck, you loose your contacts.
> Basically all database-y things seem to love back-compatibility ( if
> you're lucky ), but the idea of forward compatibility seems to
> completely bypass them; the concept that the functionality is good
> enough already, and doesn't require further file-format breakage is
> apparently not present ;->
>
> AFAIR the addressbook usages of libdb for the local addressbook were
> annoying enough in previous instances that we moved to having an
> internal version.
>
> What I'd love to see instead, is a one-shot migration to a simple plain
> text, authoritative file with the contacts and then (perhaps) optionally
> a binary cache I guess. But for the volume of data there, presumably
> slurping it and grokking it with some small / simple piece of code would
> be rather more efficient. Ultimately contact searches are in response to
> user-input, so we have loads of time to do work there.
Hhh. But. The use case you outlined directly above about where this goes
wrong also applies here: "Oh. You ran e-d-s on a machine with a version
that migrates it to Some Other Format (tm). You then add some contacts
which go into the new format. Then you go back to your old machine.
*Boing*. Same problem, your new contacts are missing :-("
Of course you can solve this by keeping the two backends around for as
long you need (e.g. 1, 2, 3, 5, ..., n-1, n releases) OR you can dictate
a policy saying that once you've migrated you can never go back.
I would expect migrating from one version of GNOME and then back again
is probably pretty problematic anyway...ultimately I think you need to
draw the line at some point.
(You can work around the forward/backward migration by for instance
having full support in version n, but not migrate the user until (n+k).
Then if the user goes back to >= n then then they can still access their
old/new data.)
Somewhat orthogonally: Also, I wonder on the performance impact of the
flat-file approach wrt, modification / deletion when dealing with ~1k
contacts.
Cheerio,
Rob
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: > Rob, > > IIRC, I had replied to Ross on a similar query, start GNOME 2.24. Still > OpenSUSE ships with in-built libdb. I'm not aware of any other distro. > > JPR, who use to maintain Evolution few years back, gave me the notes on > why it was decided to go this way (forking libdb). So if we have answers > for all those points, I'm fine for that. We don't want to break anything > thatz fine otherwise. I'm not tracking libdb at all, if you have the > answers, then lets recalculate and plan for it in 2.26. I tried to find some details on the Oracle site about any file format guarantees. I couldn't. There is some code in the file backend to try and handle upgrading. I'm not sure how well tested this code path is. Since that the vast majority of users out there have the system libdb dynamically linked into their binaries with apparently no ill effects. However, there hasn't been a major version upgrade (with incompatible file formats) for quite some time. Cheerio, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Tue, 2008-10-07 at 09:00 +0530, Srinivasa Ragavan wrote: > Oh, > > My earlier mail had that as a attachment :-) Eeek. Not enough caffeine. ;-) Cheerio, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: > Rob, > > IIRC, I had replied to Ross on a similar query, start GNOME 2.24. Still > OpenSUSE ships with in-built libdb. I'm not aware of any other distro. > > JPR, who use to maintain Evolution few years back, gave me the notes on > why it was decided to go this way (forking libdb). So if we have answers > for all those points, I'm fine for that. We don't want to break anything > thatz fine otherwise. I'm not tracking libdb at all, if you have the > answers, then lets recalculate and plan for it in 2.26. Okay. Have you got these details? It would be good to see which of those still apply, etc.. If we do decide to keep the included libdb perhaps it would be nice to strip it down to be the bare minimum that it needs to be... Cheerio, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Getting rid of shipped libdb
Since we're at the start of the cycle shall we go ahead and drop the included libdb ? and thus add a formal requirement on using the system version. AFAIK all the distributors ship with using the system version... I've updated the bug #410164 with a patch that makes this change. Regards, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS ABI changes in 2.24?!
On Sat, 2008-10-04 at 10:57 +0200, Patrick Ohly wrote: > Hello! > A user just alerted me of the fact that he cannot use the precompiled > SyncEvolution binaries on Ubuntu Intrepid, which ships Evolution 2.24. > The reason is that the version of libedataserver was bumped from > current/revision/age 10/0/1 to 11/0/0 as part of the r8703 commit (log > message quoted below). > > Why was it necessary to break backwards compatibility? The log message > doesn't say. It mentions that some code was moved into a new library > (libebackend?), but that alone doesn't necessarily break the backward > compatibility: libedataserver1.2 could have been linked against > libebackend. That way any symbol originally provided by > libedataserver1.2-9 would still have been found. It doesn't matter in > which library the symbol really is, because both libraries would be > loaded and searched automatically. For reference the bug in question is #465374. If we had linked libedataserver to libebackend we'd still have the same licensing problem. > Is there still a chance to mitigate the effect of this change? > Downgrading the version as suggested above would be the most obvious > solution, but unfortunately libedataserver-1.2.so.11 has been released > already :-/ > > Another solution would be to create a libedataserver-1.2.so.9 symlink as > part of the EDS installation. But then packagers still would have to be > aware of it and declare that the package provides > libedataserver-1.2.so.9. I don't think that Debian/Ubuntu would find this acceptable. I expect other distributions would also have objections. > > Can such ABI changes please be discussed on this list? I'm interested to > hear about them beforehand and won't notice them if they are only > discussed on IRC or in a bug tracker entry; there may be others in the > same position. Thanks! Sounds like a good idea. Cheerio, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution: Taking forward...
On Fri, 2008-07-11 at 04:21 -0600, Srinivasa Ragavan wrote: > Hello guys, > It would be really helpful if you can post a public/explicit mail with > permissions to do it, or code pointers - if you think you wrote a > piece of Evolution code & object. Permission granted for any pieces i've personally produced (those with a ChangeLog email address of [EMAIL PROTECTED]) Regards, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
