[Evolution-hackers] evolution-data-server addressbook backend
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
Re: [Evolution-hackers] evolution-data-server addressbook backend
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] WebDAV Addressbook plugin
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] Getting rid of shipped libdb
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
Re: [Evolution-hackers] Evolution: Taking forward...
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...
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
[Evolution-hackers] Error Reporting in libebook
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] Sqlite cache for address-book storage in EDS
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 > > wrote: > > > On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote: > > >> On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes > > >> 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
