Re: [Evolution-hackers] Rethinking account management

2010-12-19 Thread Rob Bradford

 (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

2008-10-08 Thread Rob Bradford
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

2008-10-07 Thread Rob Bradford
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

2008-10-07 Thread Rob Bradford
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

2008-10-07 Thread Rob Bradford
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


[Evolution-hackers] Getting rid of shipped libdb

2008-10-06 Thread Rob Bradford
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] Getting rid of shipped libdb

2008-10-06 Thread Rob Bradford
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


Re: [Evolution-hackers] EDS ABI changes in 2.24?!

2008-10-04 Thread Rob Bradford
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...

2008-09-23 Thread Rob Bradford
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