Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS

2011-03-21 Thread Matthias Braun
Am Montag, den 14.03.2011, 08:40 -0400 schrieb Adam Tauno Williams:
 On Mon, 2011-03-14 at 18:57 +0530, Chenthill Palanisamy wrote:
  On Mon, Mar 14, 2011 at 3:53 PM, Adam Tauno Williams
  awill...@opengroupware.us wrote:
   On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote:
   On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes mbar...@redhat.com 
   wrote:
Okay, this might be a long shot but I'm gonna throw it out there 
anyway:
would it make sense to look at using Xapian to index a directory of raw
vCards?
   Am not sure if its worth doing this for adress-book. Am just making an
   assumption that the
   address-book content may not be as huge as mail data. The only 
   address-book data
   that would be large enough would be GAL (exchange) and
   SystemAdressBook (groupwise).
   This is a self-fulfilling prophecy;  I and others have tried to have
   large address books... which doesn't work... so address books remain
   small.
  I agree, the *only* should be removed from the third sentence of mine,
  there could be other address-books.
  While thinking of Xapian for address-book, am not still convinced.
  One could search on various fields such as sender, subject,
  recipients, full-text search etc. in mailer often and xapian is said
  to work much better.
  Although I have not got any profiling information as such, but its
  just from hearing from multiple people.
  But for address-books, the most often used searches would be based on
  name and email. Even if the address-book has 21k or more data,
  a db with good indexing should perform better. The information stored
  will be small when compared to mail content.. Well these are just
  my observations, are there any other cases am missing ?
 
 This makes sense to me [I've no idea really how it is currently
 implemented or what the practical alternatives are].  But funny side
 note: if I just walk the DAV collection and save all the vcf files to a
 directory ... a simple python script can parse each file [using the
 vobject module], compare the values to a criteria, and report what items
 match... an order of magnitude faster than Evolution.  But the reason
 for this is mentioned below.
 
   I have a CardDAV/GroupDAV collection of ~21,000 contacts I'd love to
   have access to via Evolutions WebDAV address book.  But anything more
   than a thousand or so gets to be unbearably slow.
  AFAIR, there are some UI issues involved here which should be dealt
  with separately.
 
 True,  most importantly [at least for WebDAV address books] why the @^
 $*@ it issues a PROPFIND to the server to enumerate the collection at
 every search?!  Just search the data you have;  it really seems like
 update / synchronizing the collection and searching the collection
 should be independent events.
 
 I suppose I should get around to filing a bug about that.

The problem here is that obviously contacts on the server could have
changed since the last search. How else can you detect this? Do the
propfind results get an ETag, then this would be a good way to speed
things up.

Apart from that I could obviously add some timout, which would only
query the server every N-minutes and do faster queries from cache
only...

Anyway I'd be happy to get more input from people on the server side - I
wrote and used it only for my own contact collection which is ~200
contacts on an apache mod_dav server, because that was enough for me and
I never managed (and wanted) to setup one of the big groupwares just
for myself.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Error Reporting in libebook

2009-01-16 Thread Matthias Braun
libebook currently has a set of predefined status codes which can be
returned as a result to an operation
(GNOME_Evolution_Addressbook_Success,
GNOME_Evolution_Addressbook_RepositoryOffline, ...). This is fine to
report most common problems. However at least in my ebook-webdav backend
there are several situations which don't really match one of the
predefined error codes. For example:

- Another user has modified a contact while we were editing it:
Uploading is not allowed anymore to not accidentally overwrite the
changes.
- The server is misconfigured and returns a bad mime-type after
uploading a contact
- The server reports access denied with a detailed error message
(Example: This server is down for maintenance and will be back online
tomorrow. For emergencies call X)

For the first 2 I can only report an Other error which will result in
a completely useless error message for the user: Error adding contact:
Other error... In the last I case the more detailed error message would
be valuable additional info for the user.

I think it would be a good idea to have an additional API to report more
details along the error messages. Do you agree with this? It's probably
not optimal as you don't want translatable strings in evolution and
can't even translate the messages returned by the server. I still think
this would be way better than Other Error.

Greetings,
Matthias Braun

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution: Taking forward...

2008-11-13 Thread Matthias Braun
I hereby allow you to relicense all the code I wrote for evolution and
evolution-data-server under the terms of the LGPL v2 and LGPL v3.
This includes the code that supports addressbooks on a webdav server and
all other code I have contributed to evolution.

Greetings,
Matthias Braun

Am Freitag, den 11.07.2008, 04:21 -0600 schrieb Srinivasa Ragavan:
 Hello guys,
 
 We have had a set of problems that we are carrying around for some time like :
 
   * Copyright assignments, which is not the best way looking for the 
 future of Evolution. It sucks and sort of limits contributions to Evolution 
 and we wanted to drop it.
   * The current licensing incompatibility issues of Evolution with 
 Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/samba4 for the 
 new mapi based connector being developed for Exchange 2007.
  
 So here is the plan :
 
   * Drop Evolution copyright assignments and make it really easy to 
 contribute to Evolution
   * Move Evolution licensing to  LGPL v2 and LGPL v3 to let us re-use 
 the code more easily around the platform.  This also moves us closer to 
 Thunderbird's MPL/LGPL model. 
 
 We think this is good for Evolution and (of course) we continue to invest in 
 Evolution. We are also working to ensure we have the rights to re-license all 
 of the code. We will do the licensing/header changes as we audit the code 
 ownership situation.
 
 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.
 
 We are really excited about this and we feel this would really help Evolution 
 a lot. We need your support now for making this change and to take Evolution 
 to great heights.
 
 ´╗┐Thanks for your contributions and support.
 
 -Srini.
 ___
 desktop-devel-list mailing list
 [EMAIL PROTECTED]
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution: Taking forward...

2008-11-13 Thread Matthias Braun
I hereby allow you to relicense all the code I wrote for evolution and
evolution-data-server under the terms of the LGPL v2 and LGPL v3.
This includes the code that supports addressbooks on a webdav server and
all other code I have contributed to evolution.

Greetings,
Matze

Am Freitag, den 11.07.2008, 04:21 -0600 schrieb Srinivasa Ragavan:
 Hello guys,
 
 We have had a set of problems that we are carrying around for some time like :
 
   * Copyright assignments, which is not the best way looking for the 
 future of Evolution. It sucks and sort of limits contributions to Evolution 
 and we wanted to drop it.
   * The current licensing incompatibility issues of Evolution with 
 Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/samba4 for the 
 new mapi based connector being developed for Exchange 2007.
  
 So here is the plan :
 
   * Drop Evolution copyright assignments and make it really easy to 
 contribute to Evolution
   * Move Evolution licensing to  LGPL v2 and LGPL v3 to let us re-use 
 the code more easily around the platform.  This also moves us closer to 
 Thunderbird's MPL/LGPL model. 
 
 We think this is good for Evolution and (of course) we continue to invest in 
 Evolution. We are also working to ensure we have the rights to re-license all 
 of the code. We will do the licensing/header changes as we audit the code 
 ownership situation.
 
 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.
 
 We are really excited about this and we feel this would really help Evolution 
 a lot. We need your support now for making this change and to take Evolution 
 to great heights.
 
 ´╗┐Thanks for your contributions and support.
 
 -Srini.
 ___
 desktop-devel-list mailing list
 [EMAIL PROTECTED]
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
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-09 Thread Matthias Braun
Am Dienstag, den 07.10.2008, 16:49 +0100 schrieb 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.

You should respect the lessons learned from mbox format vs. maildir for
mails. Simply use a single file per vcard and make the creation/deletion
performance an issue of the file system which usually deals with this
quiet well.

Greetings,
Matthias

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] WebDAV Addressbook plugin

2008-03-21 Thread Matthias Braun
Hi,

I just decided to release a first beta version of my
evolution-data-server extension for addressbooks on webdav servers.

The basics are all working now (it runs fully featured and stable
connected to a mod_dav apache here). All that is missing is more testing
and the GUI part so you can easily create new addressbooks inside
evolution. Feedback would be apreciated.

http://kreacher.is-a-geek.net/~matze/webdav_ebook.tar.gz

Greetings,
Matze


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] evolution-data-server addressbook backend

2008-03-19 Thread Matthias Braun

Am Dienstag, den 18.03.2008, 10:46 + schrieb Ross Burton:
 On Tue, 2008-03-18 at 11:34 +0100, Matthias Braun wrote:
  I just started developing a custom addressbook(1) backend and have a few
  questions regarding the API. First I wonder about the functions
  get_contact_list, get_contact and get_changes. They don't seem to be
  used by evolution. Are there applications around that use them? Do bad
  things happen if I don't implement them (set the callback to NULL)?
 
 Implement them.  Evolution doesn't use them as far as I know but
 get_contact_list and get_contact will be used by other applications.
 get_changes is used by syncing tools such as OpenSync.
too bad, this means code duplication in plugins... I had hoped that
evolution might emulate the calls with the start_book_view stuff if
get_contact_list isn't available. But seems I have to code it after all.

 
  The other thing I can't get to work is authentication. If I abort an
  action with GNOME_Evolution_Addressbook_AuthenticationRequired then
  evolution is simply displaying me an error message. I would have
  expected that it asks me for username and password and calls the
  authenticate_user callback. How can I get this working?
 
 To be honest I've only looked at the backends which don't require
 authentication.  I suggest you read the LDAP backend.
 
 At a guess, make you sure implement get_surpported_auth_methods.  Also
 you'll want to call e_book_backend_notify_connection_status.

I got the authentication part working now. The trick was as you said
using get_supported_auth_methods to return plain/password as
authentication method. You also have to make sure the addressbook source
has the user and auth properties set to the username/authentication
method.

Greetings,
Matze

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] evolution-data-server addressbook backend

2008-03-18 Thread Matthias Braun
Hi,

I just started developing a custom addressbook(1) backend and have a few
questions regarding the API. First I wonder about the functions
get_contact_list, get_contact and get_changes. They don't seem to be
used by evolution. Are there applications around that use them? Do bad
things happen if I don't implement them (set the callback to NULL)?

The other thing I can't get to work is authentication. If I abort an
action with GNOME_Evolution_Addressbook_AuthenticationRequired then
evolution is simply displaying me an error message. I would have
expected that it asks me for username and password and calls the
authenticate_user callback. How can I get this working?

Greetings,
Matze

(1): If you wonder about what sort of backend I'm hacking: I'm
scratching an itch after failing to setup openldap/groupdav servers
correctly. I'm hacking a backend that works on a simple webdav server
(no groupdav extensions needed) it probably won't scale for thousands of
addresses has race conditions (an address might theortically appear
twice if 2 users modify it at the exact same time) but you can use any
webdav server and it already works nicely and fast for my 50 personal
contacts...


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers