Re: [Evolution-hackers] Evolution community meeting at #evolution-meet channel - June 20 - 3:30 PM UTC

2012-06-20 Thread Chenthill
On Wed, 2012-06-20 at 15:26 -0400, Matthew Barnes wrote:
 On Tue, 2012-06-19 at 16:03 +0530, Chenthill wrote:
  As some of you already know, I moved to some other project and
  spending most of my time there. At-least during the initial period, I
  would not be getting much time for evolution. Matthew would be taking
  forward the community meetings hence forth.
 
 We decided in today's meeting to end the monthly IRC meetings on account
 of there being so few Evolution developers left.  We agreed this mailing
 list is sufficient and actually better suited for technical discussions,
 status updates and upcoming event reminders.
 
 We'll hold team-wide IRC meetings as needed henceforth.
 
 Discussion of and consensus on this decision is posted here:
 http://projects.gnome.org/evolution/meeting-logs/2012-06-20.shtml
Oh I should have been there. Remembered all the time. Thought of reading
a piece of new code before the meeting. It was too much to digest and
slept off unknowingly.. 

Anyways e-h list should be ok as well given the amount of active
developers. If any community members wants it, they can still ask for
it.

- Chenthill.
 
 Matthew Barnes
 
 


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


[Evolution-hackers] Evolution community meeting at #evolution-meet channel - June 20 - 3:30 PM UTC

2012-06-19 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates

http://live.gnome.org/Evolution/CommunityMeet

As some of you already know, I moved to some other project and spending 
most of my time there. At-least during the initial period, I would not be 
getting much
time for evolution. Matthew would be taking forward the community meetings 
hence forth.

Thanks, Chenthill.

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


Re: [Evolution-hackers] Retiring evolution-exchange

2012-06-01 Thread Chenthill
On Thu, 2012-05-24 at 16:15 -0400, Matthew Barnes wrote:
 The release of Evolution-ActiveSync brings the number of Evolution Data
 Server backend modules for Microsoft Exchange up to four.
 
 Even if we had the manpower to adequately maintain all these, which we
 don't, four different backends for one product is getting ridiculous.
 
 Therefore I think it's time to retire Evolution-Exchange.  That module
 has seen steadily decreasing maintenance for several years, the newest
 version of Exchange it supports is now a decade old, and frankly it was
 never all that reliable anyway.
 
 As with any Free Software project, retiring Evolution-Exchange simply
 means we will cease issuing new tarballs.  3.4.x will be its last stable
 release series.  Any interested party is of course welcome to resurrect
 the project and issue new releases.
Sorry for getting back a little late. I will include the reply with
regards to evolution-groupwise as well. 

Though we have several packages that are supporting exchange. If we take
a deeper look into what versions of exchange server they support, we
might get a clear idea whether we want to retire them or not.

evolution-exchange - best backend to support Exchange 2003 servers.
There are some enterprises who are using evolution-exchange. As
evolution-exchange has been well tested in different Exchange 2003
setups, it would be better bet over evolution-mapi.

evolution-mapi, evolution-ews, evolution-activesync - all support 2007 
2010. evolution-ews is good on desktops and evolution-activesync is good
for mobile clients. We started evolution-ews considering that mapi would
be deprecated in future.

Then why not retire evolution-mapi instead of evolution-exchange ?

I do understand that you looked at the code updates and available
developers to decide. It would also be good if we choose what to support
based on, what would work as a good enterprise solution. I say
enterprise since we are here talking about exchange and groupwise.

W.r.t evolution-groupwise, it would be good to continue it until this
release. I second the reason which Akhil has mentioned in another email.
We would also need to give it sometime to see if there are people
interested in contributing there.

Thanks, Chenthill.
 If we have consensus on this I will announce it.  At this time I have no
 plans to adapt the module to the upcoming API changes.
 
 Matthew Barnes
 
 
 
 ___
 evolution-hackers mailing list
 evolution-hackers@gnome.org
 To change your list options or unsubscribe, visit ...
 https://mail.gnome.org/mailman/listinfo/evolution-hackers


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


Re: [Evolution-hackers] Retiring evolution-exchange

2012-06-01 Thread Chenthill
On Fri, 2012-06-01 at 06:57 -0400, Matthew Barnes wrote:
 On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote:
  Then why not retire evolution-mapi instead of evolution-exchange ?
 
 I hadn't considered that.  I'll defer to Milan to make that call.
 
 I thought evolution-mapi worked with Exchange 2003 servers at least in
 theory; I don't know how much actual testing that's had.  And I know
 Milan has been maintaining evo-mapi more actively than evo-exchange and
 has a good working relationship with the OpenChange developers.
 
 In any case, maintaining this many different backends for Exchange is
 ridiculous and we need to drop at least one of them given our manpower
 shortage.  I guess I don't care so much which, and am probably not the
 most qualified to choose.
 
 What do you think, Milan?
 
 
  I do understand that you looked at the code updates and available
  developers to decide. It would also be good if we choose what to support
  based on, what would work as a good enterprise solution. I say
  enterprise since we are here talking about exchange and groupwise.
  
  W.r.t evolution-groupwise, it would be good to continue it until this
  release. I second the reason which Akhil has mentioned in another email.
  We would also need to give it sometime to see if there are people
  interested in contributing there.
 
 The thing is, all of these modules are going to require significant work
 to adapt to the branch I'm about to merge -- groupwise perhaps even more
 than the rest -- and given that I don't even have access to a GroupWise
 server to test the changes I'll have to make to it, I'm highly resistant
 to bothering with it if it's not going to have a full-time maintainer
 going forward.
 
 If someone were to step forward as at least a short-term maintainer that
 could help test the changes, I would reconsider.
I can provide you the support. I will be getting into the new project
coming Monday. I can keep myself involved during free time after a
couple of weeks time..

- Chenthill.
 
 I will, however, release an evolution-groupwise 3.5.2 with the changes
 you made recently for it.  That's a fair request.
 
 Matthew Barnes
 


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


[Evolution-hackers] Evolution community meeting at #evolution-meet channel - April 18 - 3:30 PM UTC

2012-04-17 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates

http://live.gnome.org/Evolution/CommunityMeet

- Chenthill.


___
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] Memory corruption in timezone handling

2012-04-04 Thread Chenthill
On Tue, 2012-04-03 at 17:57 +0200, Christian Hilberg wrote:
 Hi,
 
 Am Sonntag 01 April 2012, um 11:13:00 schrieb Robie Basak:
  Hi freeassociation-devel,
  
  I think I've tracked down a segfault in evolution to a bug in libical.
  
  In icaltimezone.c:icaltimezone_get_builtin_timezone,
  icalarray_append(builtin_timezones, ...) is called. This can cause
  icalarray_expand() to be called, moving the entire builtin_timezones
  array and thus invalidating any previous pointers into the array.
  [...] 
 
 A  follow-up on the freeassociation-devel list asks whether Evo/E-D-S
 still use a local fork of libical or whether they're using upstream
 libical. From what the sources and configure.ac tell me, it is the latter.
 
 I guess we should communicate this to freeassociation-devel?
We moved to upstream libical long time back -
https://bugzilla.gnome.org/show_bug.cgi?id=541209 .

- Chenthill.
 
 
 Kind regards,
 
   Christian
 
 ___
 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 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] WebKit branch is ready

2012-03-30 Thread Chenthill
On Wed, 2012-03-28 at 16:26 +0200, Dan Vratil wrote:
 On Wednesday 28 of March 2012 17:59:27 you wrote:
  On Wed, Mar 28, 2012 at 4:13 PM, Daniel Vratil dvra...@redhat.com wrote:
   Hello everyone!
   
   WebKitGtk+ 1.8.0 with the important patch has been released last night,
   and so everything is in place now and I'm ready to break^W merge to
   master. The branch has been rebased two days ago, I will only bump the
   webkit dependency version later today.
   
   I hereby ask you guys for review and approval for the merge.
  
  This is great news. Im just so excited to try things out for 3.5.x. Do
  you have webkit for composer too?
 
 Hi,
 
 only email reader is done so far, I will start hacking on composer now. I 
 have 
 quite a lot of time till 3.6 and hopefully the composer won't take as much 
 time as the reader did, so if things go well, we could kill GtkHtml for good 
 in 3.6 after all :)
Wonderful!!!

- Chenthill.
 
 Dan
 
  
  -Srini.
  
   I'd suggest creating 4 or 5 new commits directly in master instead of
   actual git merge to avoid polluting master history with nearly 200
   commits of my furious development :)
   
   Cheers,
   
   Dan
   ___
   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 mailing list
 evolution-hackers@gnome.org
 To change your list options or unsubscribe, visit ...
 http://mail.gnome.org/mailman/listinfo/evolution-hackers


___
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] Evolution community meeting at #evolution-meet channel - Mar 21 - 3:30 PM UTC

2012-03-20 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates

http://live.gnome.org/Evolution/CommunityMeet

- Chenthill.

___
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] e_cal/book_open() + only_if_exists

2012-02-14 Thread Chenthill
On Tue, 2012-02-14 at 11:44 +0100, Milan Crha wrote:
 On Tue, 2012-02-14 at 11:20 +0100, Patrick Ohly wrote:
  Sorry, typo in my email. I meant the problem can be avoided by always
  passing only_if_exist=false. In other words, never use
  only_if_exists=true because it serves no useful purpose. Is that correct
  or is there some legitimate usage for only_if_exists=true?
 
   Hi,
 I do not know how the idea of only_if_exists begun, it predates me.
 The current behavior depends on each backend, some, like those remote,
 doesn't count with it at all (like for the webcal backend, it cannot
 create remote calendars, thus it always either fail or succeed, based on
 the existence of the remote calendar).
 
 I left it there when changing API due to EClient changes, because it
 seemed to me that someone can find it useful, say with local, non-system
 calendars. But maybe not.
 
 It will be good to have opinion from other team members, either former
 or current.
These are used atm for operations such as copy-to-calendar or while
changing the calendar from the event-page. My guess is that it could
have been introduced to avoid opening the calendar unless its already
opened to avoid any UI in-responsiveness. IMHO that option can be
removed and the async api's can be used to solve it unless there is some
other case.

- Chenthill.
   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


___
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] Evolution community meeting at #evolution-meet channel - Feb 15 - 3:30 PM UTC

2012-02-14 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates

http://live.gnome.org/Evolution/CommunityMeet

- Chenthill.

___
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] Home news from the Evo/WebKit Universe

2012-02-14 Thread Chenthill
On Thu, 2012-02-09 at 09:09 -0600, Matthew Barnes wrote:
 On Thu, 2012-02-09 at 12:12 +0100, Dan Vratil wrote:
  just a short note - thanks to Milan who has decied to dig into WebKit,
  embedding widgets into WebKit webview works again.
 
 That's awesome news!  I think I suffered that same bug early on in the
 branch.  Nearly drove myself crazy trying to get a simple embedded icon
 to draw.
 
 Well done to both of you!
+1 :)

- Chenthill.
 
 Matt
 
 ___
 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 mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Jan 18 - 3:30 PM UTC

2012-01-17 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates

http://live.gnome.org/Evolution/CommunityMeet

- Chenthill.

___
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] UID in vCard

2011-11-16 Thread Chenthill
On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
 Hello!
 
 I'd like to write down some thoughts on vCard UID handling in EDS.
 Andrew mentioned it on IRC, so I'm copying him.
 
 Let me define the terms to make the difference clear:
   * UID: part of the contact properties. Ideally set once when a new
 contact is created in such a way that it is globally unique
 (same semantic as iCalendar 2.0 UID, not just unique inside the
 current address book). Can and should be passed around and
 preserved when exporting/importing contacts.
   * local ID: local meta data about a contact, only relevant inside
 an address book to look up contacts. 
 
 The current situation is that EDS uses the vCard UID property for its
 own local ID. When trying to create a new contact with UID already set,
 that UID will be overwritten.
 
 This is problematic for interoperability (one cannot store a vCard
 as-is) and syncing (which would benefit considerably from a
 creator-assigned, fixed UID).
 
 This is partly an API and partly an implementation issue. The
 libebook-e_addressbook_factory D-Bus API just passes vCards, so a
 vCard property has to be used for any local ID, and UID is the one that
 is used.
 
 e_book_add_contact() doesn't have an explicit local ID retval. Clients
 have to use e_contact_get_const(contact, E_CONTACT_UID) to retrieve the
 assigned local ID. Other APIs avoid that. For example,
 e_book_add_contact_async() + EBookIdAsyncCallback return the ID
 out-of-band.
 
 The more recent EBookClient API always uses separate ID retvals.
 However, in contrast to the EBook API it specifies that these are the
 UID of the created contact and not some kind of local ID. The older API
 left that undefined and just talked of id.
 
 I see several ways forward:
  1. Accept that a contact ID as used in the EBook API is the vCard
 UID and make it possible to set that UID when creating a new
 contact. That implies for adding a contact:
   * remove the code which overwrites the UID
   * add check for existence of the UID in the address book
 and a corresponding error code if it does
  2. Use the local ID in the EBook API and support storing the vCard
 UID separately. Support lookup of a contact by UID.
 
 The advantage of the second approach is that it is potentially more
 efficient. I myself took advantage of that in the EDS-QtContacts
 bridge code. But it never was a full solution (depended on 32 bit local
 IDs, which is okay for the file backend, but not all of them, and
 required patching EDS).
 
 The disadvantage of the second approach is an API change and/or
 extension. It has some potential advantages, but as the EDS-QtContacts
 bridge is not used anymore, there is little incentive to do the extra
 work right away.
 
 So I suggest to pursue the first approach instead. I think it is
 possible for the file backend.
 
 Is it also possible for other backends? Or are some unable to store the
 UID and look up contacts (efficiently) by it? In that case we will have
 to relax the semantic of the API and accept that some backends still use
 their own local ID. Supports UID should be defined as a capability of
 the backend so that clients can take it into account.

Just went through the thread and had a small discussion with mcrha. My
preference goes with the first approach along with having the static
capability.

- Chenthill.

___
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] [Reminder] Evolution community meeting at #evolution-meet channel - Nov 16 - 3:30 PM UTC

2011-11-15 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates 

http://live.gnome.org/Evolution/CommunityMeet

- Chenthill.

___
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] Can I remove some old migration cruft, pretty please?

2011-11-07 Thread Chenthill
On Tue, 2011-11-08 at 07:34 +0100, Milan Crha wrote:
 On Mon, 2011-11-07 at 16:21 -0500, Matthew Barnes wrote:
  Users upgrading from versions 2.22 or older will just have to regenerate
  their mail caches from scratch.  I don't think that's unreasonable.
 
   Hi,
 probably the only thing is with local providers, users will loose their
 labels and other custom tags/flags on messages. I do not take it as an
 objection, though, the migration process used to crash or freeze anyway.
 You've a green from me.
Sounds fine for me as well.

- Chenthill.
   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



___
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] Since evolution-alarm-notify asks for passwords

2011-10-19 Thread Chenthill
On Wed, 2011-10-19 at 08:24 +0200, Milan Crha wrote:
   Hi,
 I cannot find the thread where this was discussed, I'm sorry, but after
 few days I found why this behaviour is pretty bad and why the
 evolution-alarm-notify didn't ask for passwords. My usecase is pretty
 simple, and I believe there are many corporate users with the same
 environment: I have entered few calendars which are accessed only when
 I'm connected to company vpn, unless they fail. When I login I do not
 have the vpn running, thus I'm asked for my passwords, thus I connect to
 vpn and then enter it (it's not prefilled, because it's not a reprompt,
 though maybe some little change on evolution-mapi could be done - these
 are evo-mapi calendars).
 
 My question is whether there can be done any better way of coping with
 this, because having the password prompts (there are two pilled,
 actually) after each and every login is just a bad experience, from my
 point of view.
Would it not be possible to store the password in gnome-keyring and be
shared. The other providers work this way, alarm-daemon would start the
authenticated calendars if it finds that the passwords is stored
gnome-keyring. It would also check whether the password can be retrieved
between intervals AFAICR.

In case a calendar is marked for alarms and if alarm-daemon was not able
to retrieve the password, would it be a good idea to show a small
warning icon in the panel, which could indicate the issue and mention
that evolution needs to be started in order to retrieve the password ?
Also inform the user that the password needs to be remembered for
alarm-daemon to work fine.


   Bye,
   Milan
 
 P.S.: Most likely unrelated, but I see I'm asked for Tasks and Notes
 passwords, at least based on the prompts, which should not be needed in
 the evolution-alarm-notify, because evolution doesn't support alarms on
 these.
I dont think the earlier behaviour used to be like this. This should be
a bug introduced at some state IMHO.

- Chenthill.
 
 ___
 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 mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Oct 18 - 3:30 PM UTC

2011-10-18 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates 

http://live.gnome.org/Evolution/CommunityMeet

- Chenthill.

___
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] [Reminder] Evolution community meeting at #evolution-meet channel - Oct 19 - 3:30 PM UTC

2011-10-18 Thread Chenthill
On Tue, 2011-10-18 at 12:30 +0200, Christian Hilberg wrote:
 Hi Chen,
 
 Am Dienstag 18 Oktober 2011, um 12:13:04 schrieb Chenthill:
  Hi,
The meeting goes as follows,
  [...]
 
 You sure the meeting is *today*, not tomorrow (i.e. Wednesday),
 as usual? Just asking. :-)
Oh my bad, not again. Its tomorrow - oct 19 :) Thanks for pointing!!

- Chenthill.
 
 
 (Bye)^2,
 
   Christian
 
 ___
 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 mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Sep 21 - 3:30 PM UTC

2011-09-19 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates 

http://live.gnome.org/Evolution/CommunityMeet

- Chenthill.

___
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] [Reminder] Evolution community meeting at #evolution-meet channel - July 20 - 3:30 PM UTC

2011-07-20 Thread Chenthill
On Tue, 2011-07-19 at 11:17 +0530, Chenthill wrote:
 Hi,
   The meeting goes as follows,
 
 * Project updates
 * Discussion on queries/decisions
 * Individual updates 
Postponing the meeting to next week Wednesday (July 27) as some hackers
wont be available today..

Thanks, Chenthill.
 
 - Chenthill.
 
 



___
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] [Reminder] Evolution community meeting at #evolution-meet channel - July 20 - 3:30 PM UTC

2011-07-18 Thread Chenthill
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates 

- Chenthill.


___
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] [evolution-kolab] towards Upstream-Integration

2011-07-07 Thread Chenthill
On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote:
 Hi everyone.
 
 Since the last announcement of the evolution-kolab team here on the list, our 
 source code (hosted at http://evolution-kolab.sourceforge.net/) has seen some 
 more polishing and now compiles on Debian/Squeeze in addition to 
 Ubuntu/Lucid. 
 We will make available a (source) release 0.0.13 soon, which contains the 
 fixes for Squeeze.
   Next week will see some performance improvements over the current state, 
 and 
 by the end of next week, I am planning to have the post-0.0.13 release ready.
 
 The code base has received quite some testing (under Ubuntu/Lucid) already, 
 mainly in the area of Kolab inter-client compatibility. Online and offline 
 operational modes are working, including conflict resolution. More testing is 
 always welcome, of course.
 
 The evolution-kolab team now feels that we have reached a state where we can 
 begin working towards upstream integration. During the planning and coding 
 phases so far, we aligned all of our project decisions with the Evolution 
 team 
 as closely as our time schedule and resources permitted. This was done in 
 order to promote for an easy upstream integration process. We would like to 
 thank everyone here who helped us in the various aspects of creating a new 
 Evolution plugin.
 
 We would very much like to be hosted at gnome.org with our project. 
 SourceForge is a nice breeding platform, but we feel it is a little too far 
 away from GNOME, and since we are a true GNOME project, we think it would be 
 nice to add evolution-kolab directly to the Evolution project at its GNOME 
 site.
 
 The first step could be to create an evolution-kolab git repository at 
 gnome.org, at least this is what came to my mind instantly. In order to get 
 the prerequisites right, I have applied for a GNOME account with git access. 
 This has been vouched for by the Evolution team (thanks, Matt), and I have 
 received confirmation from the GNOME account management team today.
 
 Since neither my kernel concepts evolution-kolab team mates nor myself have 
 done upstream integration for an Evolution plugin yet, I would like to know 
 how we should best proceed from here. If there is any reading we should have 
 done prior to further acting, we'll gladly accept pointers to the relevant 
 documents. David (or anyone else involved there), I heard that you did the 
 same with your EWS team recently, so if there are any lessons-learned which 
 we 
 should heed to, we will also be happy to know. Long story short, we will just 
 be happy for any directing through this process so we can get through it 
 smoothly.
You could create a package naming eg: evolution-kolab and create a new
repository in git.gnome.org. http://live.gnome.org/Git/NewRepository
has all the details required.

Thanks, Chenthill.
 
 Thanks a lot in advance,
 Kind regards,
 
   Christian
 
 
 ___
 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 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] improve PHOTO support in libebook/EDS

2011-07-07 Thread Chenthill
On Thu, 2011-07-07 at 10:48 +0200, Patrick Ohly wrote:
 On Wed, 2011-07-06 at 16:16 -0400, Tristan Van Berkom wrote:
 [staging directory for out-of-band photo data transmission]
  This alternative proposal is strictly regarding the photo data for
  which the server must take ownership of I assume, correct ?
 
 Yes.
 
  I might not have been clear enough in my proposal but I only 
  intend for new or modified photos to be sent to the addressbook.
 
 Understood. I personally don't mind the D-Bus overhead in these cases
 because I consider them rare. But there are people who run massive write
 benchmarks against EDS anyway and do flag low performance in them as a
 problem. So if we can find a solution that also optimizes the write
 performance, then it would be better.
 
  The staging directory you propose if I understand it correctly
  would also be used under only the same circumstances, I suppose
  the questions are:
o What is faster: writing a file to a staging directory and 
  then moving it to a permanent location or sending the blob
  once over D-Bus and saving it to the permanent location.
 
 If the photo data needs to be stored as file and moving the file into
 its permanent location can be done with a rename, then the staging
 directory approach is faster. I expect writing the file to be equally
 fast, regardless of who does it. Sending inline data adds D-Bus overhead
 (considerable for large chunks of data!) and encoding/decoding overhead.
I like the staging directory approach. Would it be possible for
implementing the logic to convert the inline data -file inside 
e_book_client_add_contact so that the clients need to worry about
changing the code ?

- Chenthill.
 
o What is more reliable ? (it seems that there are less
  points of failure when sending the blob but I could be wrong).
 
 Agreed. I tried to mitigate that with the rules around cleaning up the
 staging directory.
 
  Perhaps the staging directory is a little faster when batching lots 
  of photo modifications during a 'sync' operation ? (the client
  gets to write to disk while waiting for the server to be ready
  for the next batch of contact additions perhaps ?)
  
  At any rate, if it's judged that the performance gain of using
  a staging directory is worth the added complexity then let's do it.
 
 I'd like to hear some other opinions about this. Ross?
 
  I think the more important issue at hand is that to offer
  a reliable api for EBookView then the backend has to track
  the views which have received notification of the contact
  modifications.
  
  In other words when I have an EBookView and I have been
  notified that a contact exists with a photo at a given uri path,
  then until I receive notification that that uri is invalid,
  removed or replaced with a new one... I should be able to
  access that file.
 
 I don't see this as a problem. When a process fails to load a photo
 because the contact was already removed on the server together with that
 photo, then shortly after the attempt to read the photo the process will
 get the notification that the contact is gone and thus the process no
 longer needs the photo.
 
 I also think that this is a very rare situation. Definitely doesn't
 justify adding complex code to the D-Bus interface between libebook and
 EDS.
 
  Another hard limitation is regarding storing uris for which
  you don't want the addressbook to assume ownership of.
  
  The clean way as far as I can see is whoever is responsible
  for adding an 'alien uri' to an addressbook is responsible
  for removing that entry from the addressbook at the time
  that the uri might be deleted.
 
 Agreed. But I don't think there is a clean and efficient way of solving
 this. It'll be much simpler to accept that there will be URIs that point
 to deleted files.
 
 The intention is to not use URIs pointing to arbitrary local files.
 Therefore we don't need to provide a solution that assists apps who want
 to do that.
 
  Well... perhaps we should just swallow the ugly race and do nothing
  about it and say that:
a uri might be invalid from time to time directly before your view
 receives notification of the removal ?
  
  Would that be acceptable ?
 
 Yes.
 



___
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] [PATCH] evolution-ews: implement Exchange categories as evolution labels (read only)

2011-05-24 Thread Chenthill
On Mon, 2011-05-23 at 16:01 +0100, David Woodhouse wrote:
 On Mon, 2011-05-23 at 17:46 +0400, James Bottomley wrote:
  I think you probably need me to get a feel for evolution development
  initially before you set me loose in the repo ...
 
 Why? It's mostly my baby, and I'm a kernel hacker too... :)
 
  Incidentally, I presume you use bugzilla for bugs?  I just ran across
  one experimenting with Categories.  Apparently if I change the category
  on the outlook webserver, it causes us to delete the email (with or
  without my patch applied).
 
 That'll be a bug that Chen introduced on Thursday. I've reverted those
 commits for now. We're currently between Alpha and Beta releases; I
 don't mind a little bit of 'churn', but I draw the line at data loss :)
 
 Sorry about that.
Sorry for it, its a bad assumption I made. Fixed it in master.

- Chenthill.
 
 Note that HEAD doesn't compile at the moment because of something
 committed by Pavel Ocheretny pochere...@src.gnome.com last night.
 I'll change that to a real, working email address and *POKE*.
 



___
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] Indexing of mail body? how it works?

2011-05-20 Thread Chenthill
On Fri, 2011-05-20 at 13:27 +0200, Nicolas Michel wrote:
 Hello,
 
 I had used Ubuntu for some years. Some weeks ago when gnome 3 was 
 realesed I decided to switch to Archlinux.
 So I'm now with archlinux 64 bits - gnome 3 with gnome-shell and 
 Evolution 3.0.1-1.
 
 A search on body-content is very very slow.
 
 I have to say that I have a hudge INBOX : ~18500 mails (but it was not a 
 problem on Ubuntu).
 
 So here are my questions :
 - is it because of the Evolution package on Ubuntu is patch with 
 something from canonical that increase the speed of search on body content?
 
 - is it because of the newer version of Evolution? (3.0.1-1 on Archlinx 
 insted of 2.30 on the last Ubuntu I tested on)
 
 - In that latest case, is it a regression and if yes, will you fix it?
 
 - Or maybe I only have to install another package that will index my 
 Evolution's mail?
 
 My only purpose is to be able to make search on body content as fast as 
 I did on Ubuntu. Even with 18500 mails, such a search took only a few 
 seconds on Ubuntu (2,3 or 4 seconds ; now on arch it takes 30-40 or 50 
 seconds).
Are your mails stored in local system folders or are they local folders
stored as mbox or maildir or do you have them on some server, cached
them using imap or pop ?

- Chenthill.
 
 Many many thanks!
 Nicolas.
 ___
 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 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] 32 bit IDs in contact file backend

2011-05-18 Thread Chenthill
On Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote:
 On Di, 2011-05-17 at 18:49 +0530, Chenthill wrote:
  On Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote:
   |  Further work if you agree in principle:
   |  * let clients query whether all contacts have the simplified ID -
   |could be done with the dynamic capabilities that I mentioned in
   |the e-client API thread; avoids reading all contact (UIDs)
  This sounds like a better solution than adding constraints on eds end.
 
 I prefer to think of it as an additional promise to the libebook user,
 not a constraint.
 
  One possibility which came to my mind [requires more thoughts] was to
  bring the uid generation (e_book_backend_file_create_next_uid) function
  into EBookBackend as a virtual function. Then you could have a external
  backend for qtcontacts subclassing EBookFileBackend and over-riding the
  create_next_uid function alone. 
  
  I haven checked if other backend's would need this virtual function
  though. Maybe webdav might use it ?
 
 And then what? Build and maintain out-of-tree MeeGo versions of all
 backends?
Well, if you were thinking on supporting all backends using Qtcontacts,
it is never a solution. I suggested looking at the initial patch
attached, which meant only for file backend. Changing the ids to use 32
bit ids just for file backend also becomes irrelevant if the intention
is to support all backends, as its clear that servers like
exchange/groupwise create uids as strings which cannot be controlled by
eds.

  Quite frankly, patching the existing backends sounds less
 risky to me. Of course, including these changes upstream would be best.
I agree, but we need to find a better solution than the one which is
proposed to suit all backend's.

- Chenthill.

___
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] 32 bit IDs in contact file backend

2011-05-17 Thread Chenthill
On Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote:
 On Di, 2011-05-17 at 13:27 +0100, David Woodhouse wrote:
  On Tue, 2011-05-17 at 14:04 +0200, Patrick Ohly wrote:
   On Di, 2011-05-17 at 12:38 +0100, David Woodhouse wrote:
Even if we *didn't* have immediate plans to use other back ends like EWS
with this setup, that would be entirely the wrong thing to do, surely?
   
   I'm not so sure. We are pitching EDS as an alternative for other storage
   solutions that are highly optimized (= limited!) for specific use cases.
   What you are suggesting is that any attempt to add optimizations for a
   specific combination of app + EDS + backend is wrong and should be
   avoided. My feeling is that EDS will simply not be used at all unless
   such optimization are acceptable.
  
  [EDS upstream]
  
  I have no objection to an *optimisation*. You seemed to be describing a
  *fix*, not an optimisation.
  
  An *optimisation* allows things to work faster or more efficiently, when
  they were already working before.
  
  So if you expose an extra '32bit-numeric-uid' in your static
  capabilities for the back end, and the user can make use of that to
  operate more efficiently by bypassing the permanent uidstring-integer
  mapping, then I'm happy with that.
 
 That was the plan. From the original email:
 
 |  Further work if you agree in principle:
 |  * let clients query whether all contacts have the simplified ID -
 |could be done with the dynamic capabilities that I mentioned in
 |the e-client API thread; avoids reading all contact (UIDs)
This sounds like a better solution than adding constraints on eds end.
I was for a moment confused on this and david's reply was right on
target :)

One possibility which came to my mind [requires more thoughts] was to
bring the uid generation (e_book_backend_file_create_next_uid) function
into EBookBackend as a virtual function. Then you could have a external
backend for qtcontacts subclassing EBookFileBackend and over-riding the
create_next_uid function alone. 

I haven checked if other backend's would need this virtual function
though. Maybe webdav might use it ?

- Chenthill.
  But *only* if it really is an
  optimisation, and designed such that the code still works (via the
  mapping) without it.
 
 I can't promise that the code will work without it right away because
 the mapping hasn't been implemented yet due to lack of time. See also:
 http://lists.meego.com/pipermail/meego-dev/2011-May/483078.html
 
 



___
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] [Reminder] Evolution community meeting at #evolution-meet channel - May 18 - 3:30 PM UTC

2011-05-16 Thread Chenthill
Hi,
 The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates

Check out http://live.gnome.org/Evolution/CommunityMeet for more details.

- Chenthill.


___
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] EBookBackendSqliteDB comments

2011-05-09 Thread Chenthill
, 
 \
  folder_name TEXT,
 \
  sync_data TEXT,  
 \
  bdata1 TEXT, bdata2 TEXT,
 \
  bdata3 TEXT);
 
 stmt = sqlite3_mprintf (CREATE TABLE IF NOT EXISTS contacts  
 \
   ( folder_id INT,
 uid  TEXT,   \
 nickname TEXT, full_name TEXT,   \
 given_name TEXT, family_name TEXT,   \
 email_1 TEXT, email_2 TEXT,  \
 email_3 TEXT, email_4 TEXT,  \
 vcard TEXT,
 PRIMARY KEY (folder_id, uid) ) );
 
On address-book deletion, dropping a table is far better than querying
and deleting all the contacts that matches a folder id. But the
frequency of deleting address-book's may be less.

So I went for a quick search and found this,
http://stackoverflow.com/questions/784173/what-are-the-performance-characteristics-of-sqlite-with-very-large-database-files
which shows using mutltiple tables is better. I have not personally done
any tests regarding this.

 As an extra bonus that means you could do autocomplete type
 queries in a single SQL query.
AFAIK with the current design of eds, each address-book would be queried
separately and would not benefit by this.

- Chenthill.
 
 
 
   sean
 ___
 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 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] EBookBackendSqliteDB comments

2011-05-09 Thread Chenthill
On Fri, 2011-05-06 at 08:56 +0200, Milan Crha wrote:
 (Please do not reply to me, reply to the list, I read the list and I
 prefer to Ctrl+L while your message avoids this feature for me. Thanks
 for your understanding.)
 
 On Thu, 2011-05-05 at 12:23 +0530, Chenthill wrote:
   you scary me. Could you repeat where is written information about a
   design you chose for this, how it correlates with actual backend
   cache(s) (we do not want to loose functionality here) and maybe why done
   so?
  Well, I have not started on the meta-data storage yet :) Just have a
  table for it. There is no specific design for it. 
 
   Hi,
 my above question wasn't only about meta-data, it was a general question
 what are you doing and how are you doing that. Without that answered
 it's just confusing. I will appreciate something like we have now these
 options, storing these values... and we will have it changed to this
 which will be doing this and this. I believe you have it somewhere
 done, I only didn't notice where. I'm sorry for that.
 
 For example, you mentioned once that there should be benefical to use
 only summary columns to be returned for some cases, like autocomplete,
 which doesn't require fully populated contacts. It makes sense from my
 point of view and I will add 
 
 e_book_client_view_set_restriction_fields_sync (..., const GSList
 *fields_to_fetch, ...)
 
 which will set list of field names to be fetched only on a view.
Yup that is possible.  This would also need another column mentioning
whether the contact is fully cached or not, will add the same.

 
 Another thing, I do not understand much why we are talking about XML
 here. Why to combine two approaches when you have one already, the
 database? Though of course, if it's just meant that the key-value pair
 can store (the value part) just anything the caller wants, then yes, I'm
 all fine with it.
Its just about the key-value pairs.

   I recall us chatting about this on IRC or somewhere one day and one
   point was that the contacts will not be stored in a binary form, but
   rather as separate files. What Sean wrote earlier sounds like you
   changed your mind in this point. I do not think it's a good idea, see
   how often the sqlite folders.db file in camel is broken, and users are
   adviced to delete it. Will they loose all their contacts in such
   situation?
  As I already said seanus on irc, I will be evaluating the performance
  between having vcards as files Vs having it in db and then choose the
  one which would be best. So the code for both will be there and we can
  choose between them over after testing. I was also thinking of providing
  it as an option for the backends to choose once i complete the testing..
  So what we discussed stays the same :)
 
 This is not only about performance, my main concerns are these:
 a) if something fails with db file, user's data are safe
 b) users can take their contacts anytime and import them on another
 machine, in case of hard disk crash, partial backup or anything like
 that
I hope seanus's reply addresses this. For remote address-book's if db is
corrupt, the local keys like 'last-modified' time would be lost, so we
would anyways cache all the data again even if the vcards might be there
to ensure that we are in sync with the server.

I will check the performance impact and if there is no big difference,
will go for storing them as separate files. If there is a considerable
difference, will provide options for both.

 c) folders.db files tend to grow indefinitely. That's another point
 why I do not like one file per account.
[i missed say this in the previous reply to seanus, so just adding it
here]
My idea here was to make it configurable, so that all personal
address-books can use one file and a relatively bigger address-book like
GAL can use a separate db file. 
http://git.gnome.org/browse/evolution-ews/tree/src/addressbook/e-book-backend-sqlitedb.h

Rest I hope I have answered in another reply to seanus.

- Chenthill.
 
 An example: my evo-mapi account has 4 addressbooks (one is GAL). I would
 really prefer to have them separated, not in one large file. Not talking
 about possible (even unlikely) UID clashes between separate
 addressbooks. Will it also mean that each local addressbook will be
 stored in one large db? Please do not do that.
 
 As I said in the very beginning, I still do not see what you are doing
 and how; it might be a good time to open the code and check that out :)
   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


___
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] EBookBackendSqliteDB comments

2011-05-05 Thread Chenthill
On Wed, 2011-05-04 at 13:04 +0200, sean finney wrote:
 Hi Everyone,
 
 I spoke with chen on IRC this morning and got hinted at a preliminary
 implementation of EBookBackendSqliteDB sitting in -ews.  Since there
 are some benefits of something something like this make it's way to
 a common place that could be used by -mapi as well, I thought I'd do
 a quick feasability review to see what problems there might be.
 
 Questions/commments/suggestions follow.  Please let me know what you
 think!
 
  * No backend _get_contact/_get_contacts equivalent.  Should be
easily implemented.
_get_vcard_string == _get_contact, i have not added an API return
EContact to let the callers decide whether they want to parse the string
to EContact.

i have not observed any use cases for get_contacts needed by the
backends. _book_backend_sqlitedb_search would server the
_get_contact_list API in the backend and also for querying using a
search query to fetch the contact list.

  * _add_contact/_remove_contact should be renamed to 
_add_contacts/_remove_contacts to be consistant with other backend
methods that take lists.
Makes sense as it already acts on multiple contacts.

  * but also having a _add_contact/_remove_contact that takes just a uid
(similar to other backends) would be useful
remove_contacts already takes only uid. I do not know how far
_add_contact with just the uid would be helpful. Which backend would
need it ?

  * -mapi seems to use one cache per-profile-per-folder, but the sqlitedb
backend takes these as calling parameters.  Not really a problem and
I think it may be reasons to have one cache db anyway, so this is
just more of an observation.

  * _get/_set/_delete interfaces are needed for cache metadata (last modified,
etc).
Am working on it atm.

  * if folder metadata is going to be free-form, it could be better to have
a key-value table ( folder_id_id int, key_name text, value text ) rather
than arbitrarily numbered text/binary fields.
I was thinking of allowing the backends to store key value pairs using a
bdata column which could be populated with xml key-value data. Would be
it be good idea ?

  * not sure of this one: given there may be multithreaded access to the db,
do we need to provide any external big locks on reads/writes?  maybe
the built in sqlite stuff is sufficient.
  * not sure of this one: beyond the COMMIT statements, should there be
something to periodically sync the db beyond the backend finalize 
 method?  
afaik it would be taken care of sqlite vfs and commit should be enough.

Unsure with commit is sufficient to get consistant on-disk in case of
crash, etc.
  * do we need a set_populated/is_populated equivalent?  or maybe that could
be solved in the cases it's needed wtih metadata.
I think I added it and removed later thinking it might be redundant with
sync_data column, but re-thinking now am clear both are independent.
Will get that added...

  * do we need a set_time/get_time equivalent?  or maybe that could
be solved in the cases it's needed wtih metadata.
There is a sync_data column which can be used for the same with either
last_modified date or sequence numbers or some synchronization text.

 
 @chen: I don't know how active you plan to be on this, but if you're looking
 to offload any work, I can pick up anything that results from the above if
 you like.  Just let me know!
The work is almost over, but will let you know once i finish the testing
and you can directly make changes if you require anything more there :)

- Chenthill.
 
 
   Sean
 


___
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] EBookBackendSqliteDB comments

2011-05-05 Thread Chenthill
On Thu, 2011-05-05 at 11:20 +0530, Chenthill wrote:
 
   * not sure of this one: given there may be multithreaded access to
 the db,
 do we need to provide any external big locks on reads/writes?
 maybe 
Though sqlite has it, i have read in the FAQ that it recommends
applications not to perform any read operation while a write is in
place. And I did not want to our app to loop of _BUSY message, so I have
added a RW lock to avoid that.

- Chenthill.


___
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] EBookBackendSqliteDB comments

2011-05-05 Thread Chenthill
On Thu, 2011-05-05 at 13:53 +0200, Milan Crha wrote:
 On Thu, 2011-05-05 at 11:20 +0530, Chenthill wrote:
* if folder metadata is going to be free-form, it could be better
  to have a key-value table ( folder_id_id int, key_name text,
  value text  ) rather than arbitrarily numbered text/binary
  fields.
  I was thinking of allowing the backends to store key value pairs using
  a bdata column which could be populated with xml key-value data. Would
  be it be good idea ?
 
   Hi,
 you scary me. Could you repeat where is written information about a
 design you chose for this, how it correlates with actual backend
 cache(s) (we do not want to loose functionality here) and maybe why done
 so?
Well, I have not started on the meta-data storage yet :) Just have a
table for it. There is no specific design for it. 

 
 Like in the above quoted text, is that to replace keys.xml file (it's
 from calendar, I know, but you know what I mean)? Or what do you call
 meta-data? 
In calendar terms, yes.

 I want to be able to store my own keys per account (not per
 item, it's another thing which scary me, one addressbook cache file per
 account, really?) 
Meta-data table is one for an account and folder meta-bata will form the
rows. 

 Be sure that parsing bdata is a pain, and always will,
 especially when you already are in a database world, where are tables
 and relations between them pretty common and nature.
This is the reason I was thinking whether it would be good idea to have
a abstract API to store extended (apart from sync_data, populated
columns etc.) key-value pairs if the backend needs. This can form the
xml and store it as bdata. Now the bdata would not be exposed to the
callers. Is there any other better way to do this ?

 
 If I recall correctly then populated and last_modified were also
 stored as keys in the background, but backend could drop them
 accidentally, when accessing through keys directly. It sometimes can
 be considered a benefit, but it usually isn't. If I have specialized API
 to access these keys, then I should use it exclusively. I think.
For the commonly used keys such as the above we would have specialized
API's and they would be having separate columns on a per-folder basis.

 I recall us chatting about this on IRC or somewhere one day and one
 point was that the contacts will not be stored in a binary form, but
 rather as separate files. What Sean wrote earlier sounds like you
 changed your mind in this point. I do not think it's a good idea, see
 how often the sqlite folders.db file in camel is broken, and users are
 adviced to delete it. Will they loose all their contacts in such
 situation?
As I already said seanus on irc, I will be evaluating the performance
between having vcards as files Vs having it in db and then choose the
one which would be best. So the code for both will be there and we can
choose between them over after testing. I was also thinking of providing
it as an option for the backends to choose once i complete the testing..
So what we discussed stays the same :)

- Chenthill.
   Bye,
   Milan
 
 P.S.: I confess I didn't open your code, I only read this thread.
 
 ___
 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 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] New 'eclient' branch in eds

2011-04-26 Thread Chenthill
On Thu, 2011-04-21 at 08:32 +0200, Milan Crha wrote:
 On Tue, 2011-04-19 at 17:00 +0200, Milan Crha wrote:
  On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote:
   I would like you to a incorporate some change to the free/busy api.
   Some servers allow querying free/busy information
   for multiple users at a time and the results appear in a iterative
   fashion. The freebusy information of some
   users are delivered first, while the server keeps fetching other
   user's free/busy information. So if we could have he
   FreeBusy api such as this, we could leverage those features,
   
   ECalClientFreeBusy
   e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t
   start, time_t end, const GSList *users, GCancellable *cancellable,
   GError **error);
   (with a async counter-part)
   
   Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar
   *user, GSList *ecalcomps)
   
   The clients could watch for the signal and update the freebusy
   information as and when they receive from eds. 
 
   Hi,
 I rethought my thoughts about this and I think I follow your idea more
 closely now. If I try to rephrase it, then it might be:
 
 On the server side, add new
e_data_cal_notify_free_busy_data (..., const GSList *ecalcomps);
 which invokes a signal on the D-Bus connection about (partial) result
 for a free/busy request (note it doesn't provide user separately).
 This signal will be valid only while a get_free_busy request is running.
 Calling e_data_cal_notify_free_busy_data() out of these functions will
 not fail, but the ECalClient consumer may not expect that being done.
 With this limitation we'll have a possibility to cancel pending request,
 if needed. The e_data_cal_respond_get_free_busy() will have no return
 values.
We could term it start_free_busy..

 
 On the client side, the 'finish' function will be also void and any
 information about free-busy will be available exclusively in a
 free-busy-received signal, which will have a parameter GSList
 *ecalcomps.
Once a free_busy_done signal is received, the finish function can be
called. Yup and on the whole I agree to what you have mentioned here.

Thanks, Chenthill.
 
 I hope we are on the same line now. If you agree, then I'll make a
 change in this way.
   Thanks and 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


___
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] [Reminder] Evolution community meeting at #evolution-meet channel - April 20 - 3:30 PM UTC

2011-04-19 Thread Chenthill Palanisamy
Hi,
 The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates

Check out http://live.gnome.org/Evolution/CommunityMeet for more details.

- Chenthill.
___
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] New 'eclient' branch in eds

2011-04-19 Thread Chenthill Palanisamy
On Mon, Apr 18, 2011 at 10:18 PM, Matthew Barnes mbar...@redhat.com wrote:
 On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote:
 I just created a new branch 'eclient' in eds [1] where is added my work
 on the new API which will deprecate EBook/ECal. It is following glib/gio
 async pattern and, I believe, makes things more coherent.

 Thanks for posting this, Milan.  I want to emphasize how important these
 new APIs are and ask everyone to look it over and provide comments.

 I had a sneak peek at this over the weekend and jotted some notes.  So
 far I've only reviewed in detail the client-side headers because that's
 what I'm most concerned about getting right.  The rest of it can be
 tweaked and changed as needed -- even the backend APIs are never truly
 frozen.  But the client-side APIs *will* be frozen, since that's what
 other projects will be migrating to and attempting to use.

 The new client-side APIs are:

 EClient (abstract base class)
 http://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-client.h?h=eclient

 ECalClient (replaces ECal)
 http://git.gnome.org/browse/evolution-data-server/tree/calendar/libecal/e-cal-client.h?h=eclient
I would like you to a incorporate some change to the free/busy api.
Some servers allow querying free/busy information
for multiple users at a time and the results appear in a iterative
fashion. The freebusy information of some
users are delivered first, while the server keeps fetching other
user's free/busy information. So if we could have he
FreeBusy api such as this, we could leverage those features,

ECalClientFreeBusy
e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t
start, time_t end, const GSList *users, GCancellable *cancellable,
GError **error);
(with a async counter-part)

Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar
*user, GSList *ecalcomps)

The clients could watch for the signal and update the freebusy
information as and when they receive from eds.

- Chenthill.

 EBookClient (replaces EBook)
 http://git.gnome.org/browse/evolution-data-server/tree/addressbook/libebook/e-book-client.h?h=eclient

 ECredentials (authenication)
 http://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-credentials.h?h=eclient


 I'll split my comments into two posts so this doesn't get too
 overwhelming.  Simple, hopefully non-controversial stuff here and
 meatier topics in a separate post.  Overall I'm pretty happy with
 the APIs.


 * There's some overlap between the new EClient API and the new
  ESource API that I'm working on.  Some functions will need to be
  dropped once the new ESource API is in place, so I don't know if
  you want to do this now or wait.

  ESourceList is being removed so obviously any functions involving
  ESourceList will be dropped:

    e_client_util_get_system_source()
    e_client_util_set_default()
    e_client_util_get_source_for_uri()
    e_cal_client_get_sources()
    e_book_client_get_sources()

  We will no longer refer ESources using URIs.  We will only refer
  to ESources by their unique ID string.  So the following functions
  will be dropped:

    e_client_get_uri()
    e_cal_client_new_from_uri()
    e_book_client_new_from_uri()

  Default sources will be tracked using the new ESourceRegistry API,
  so the following functions will be dropped:

    e_cal_client_set_default()
    e_cal_client_set_default_source()
    e_book_client_set_default()
    e_book_client_set_default_source()

  There's a few functions that I think are too trivial to keep in light
  of the lookup capabilities of ESourceRegistry.  I'd like to keep the
  EClient APIs as slim as possible initially and drop these functions:

    e_cal_client_new_system()

      Instead do:

      source = e_source_registry_lookup_by_uid (registry, system);
      client = e_cal_client_new (source, source_type, error);

    e_cal_client_new_default()

      Instead do:

      source = e_source_registry_get_default_calendar (registry);
      client = e_cal_client_new (source, E_CAL_SOURCE_TYPE_EVENT, error);

      (similar functions exist for tasks and memos)

    e_book_client_new_system_addressbook()

      Instead do:

      source = e_source_registry_lookup_by_uid (registry, system);
      client = e_book_client_new (source, error);

    e_book_client_new_default_addressbook()

      Instead do:

      source = e_source_registry_get_default_address_book (registry);
      client = e_book_client_new (source, error);


 * We should use GIO error codes whenever possible, and I see quite a bit
  of overlap here.  I think following error codes should be dropped:

    E_CAL_CLIENT_ERROR_SUCCESS
    E_BOOK_CLIENT_ERROR_SUCCESS

      There's no need for an error code for successful operations.

    E_CAL_CLIENT_ERROR_INVALID_ARG
    E_BOOK_CLIENT_ERROR_INVALID_ARG

      Use G_IO_ERROR_INVALID_ARGUMENT.

    E_CAL_CLIENT_ERROR_BUSY
    E_BOOK_CLIENT_ERROR_BUSY

      Use G_IO_ERROR_BUSY

Re: [Evolution-hackers] EWS MessageInfo leak wtf

2011-04-11 Thread Chenthill Palanisamy
On Sat, Apr 9, 2011 at 4:08 AM, David Woodhouse dw...@infradead.org wrote:
 ==5510== 41 bytes in 1 blocks are possibly lost in loss record 8,473 of 17,762
 ==5510==    at 0x4A05E46: malloc (vg_replace_malloc.c:195)
 ==5510==    by 0x3B6A048B52: g_malloc (gmem.c:164)
 ==5510==    by 0x3B6A06101D: g_strdup (gstrfuncs.c:102)
 ==5510==    by 0x1693D7B1: ews_message_info_clone (camel-ews-summary.c:75)
 ==5510==    by 0x1693E4FD: camel_ews_summary_add_message_info 
 (camel-ews-summary.c:417)
 ==5510==    by 0x16940ADD: camel_ews_utils_sync_created_items 
 (camel-ews-utils.c:973)
 ==5510==    by 0x16939819: sync_created_items (camel-ews-folder.c:660)
 ==5510==    by 0x16939B41: ews_refresh_info_sync (camel-ews-folder.c:750)
 ==5510==    by 0x4C78C99: camel_folder_refresh_info (camel-folder.c:1156)
 ==5510==    by 0x33B6E7F0F7: mail_msg_proxy (mail-mt.c:469)
 ==5510==    by 0x3B6A06BBC3: g_thread_pool_thread_proxy (gthreadpool.c:319)
 ==5510==    by 0x3B6A069445: g_thread_create_proxy (gthread.c:1897)
 ==5510==

 Can't repeat it; don't know how it happened... except of course that it
 obviously happened when SyncFolderItems returned some created items.

 The frame in ews_message_info_clone() at camel_ews_summary:75 is setting
 mi-change_key on the newly cloned MessageInfo:
 http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-summary.c#l75

 (I'm also *sure* it happened after commit 17bd5273 in which I fixed a
 consistent leak of our mi-change_key by adding a message_info_free()
 method to our class. Not only do I remember it that way, but the
 timestamp of my valgrind log file is about four hours later than that
 commit, and the *other* valgrind warnings that the -change_key leak
 caused are noticeable in their absence.)

 I'm confused by the use of camel_message_info_clone() in the first line
 of camel_ews_summary_add_message_info():
 http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-summary.c#l417
 There is *one* caller of this function, and it's the one in the above
 backtrace — camel_ews_utils_sync_create_items():
 http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-utils.c#l973

 And that *creates* a new MessageInfo of its own... which AFAICT never
 gets freed, although valgrind doesn't seem to be complaining about that,
 and I don't know why.

 Removing the clone in camel_ews_summary_add_message_info() and just
 using '(void *)info' seems to work just as well; I'm not really sure
 what's going on here. And either way, I've never been able to repeat the
 above warning.

 Chen, was there a reason for the clone? And why isn't valgrind
 complaining about it? Can anyone see something that would cause the
 above complaint that it *did* make?
The ews_summary_clone seems un-necessary there. I picked up some code from the
imapx provider and certainly did a mistake there. The const identifier
for the CamelMessageInfo in the
signature of the function and message_info_clone can be removed.

- Chenthill.

 --
 dwmw2


___
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] EDS improvements for MeeGo

2011-04-05 Thread Chenthill Palanisamy
On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly patrick.o...@gmx.de wrote:
 On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote:
 On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly patrick.o...@gmx.de wrote:
  Hello!
 
  I have published some more information about our plans for MeeGo:
  http://wiki.meego.com/Architecture/planning/evolution-data-server
  http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements
 I was going through the eds-improvements part of it. In the
 performance improvement
 mentioned at 'Optional parsing of data in the client'. I was wondering
 if having a new lib[ecal/ebook]
 api that can return two kind of meta data,
 + one for populating the view [similar to message-info in mailer]
 + for querying the changed information [mentioned at 'change tracking+
 atomic updates' section'.

 I don't quite follow. Can you be more specific?
I was suggesting to pass the summary-info required for the view as a
dbus object (which requires
creation of an object similar to CamelMessageInfo) which could save
string-vcard convertions and vice-versa in eds and
also remove the need for delayed parsing. But as I do not understand
the use case, the suggestion may not even be relevant..


 I just noticed that e_book_get_book_view() already has a GList
 *requested_fields parameter. Is that used and/or implemented anywhere?

 The special case relevant for a QtContacts bridge would be to get just
 the UID. I don't think that this is covered by the current file backend,
 but at least the libebook/D-Bus/backend API should be in place to
 implement it.
Ok this gives me some idea. But, use cases would make things clear.

- Chenthill.

 Thick clients like evolution can still use the existing apis to avoid
 much changes unless there is a significant improvement
 in performance.. Maybe good to have some profiling data as well ?

 I have asked my colleagues working on the contacts app in MeeGo about
 use cases they care for.

 --
 Bye, Patrick Ohly
 --
 patrick.o...@gmx.de
 http://www.estamos.de/



___
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] Maintenance fork for Evolution / EDS 2.32

2011-04-05 Thread Chenthill Palanisamy
On Mon, Apr 4, 2011 at 12:23 PM, Milan Crha mc...@redhat.com wrote:
 On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote:
 That's great; thanks. I'll do a little more testing on the patches
 I've cherry-picked into my trees, and then unless someone else has
 objected in the meantime I'll push them.

        Hi,
 I objected against this many times, directly to you, on IRC, with no
 effect, obviously. If I recall correctly, the reason why release-team
 decreased releases is that distributions were *not* using .2 release.
 Which is just the opposite you are trying to convince us. If they are
 not using official releases, why should they use unofficial branch?

 By the way, how would you look for a fix user reported to your
 distribution, as a distribution maintainer? The work-flow, as I
 understand it, is like this:
 a) user enters a bug report in your distro bugzilla
 b) maintainer gathers enough information to identify the issue
 c) check upstream bugzilla for a duplicate or possible fix
 d) decide on the change whether backport or indicate will be fixed
   in the next stable/unstable release

 Note that I do not expect anyone looking into git branch for a
 particular fix, with a very good reason, they would rather check in
 bugzilla, which offers much better searching ability and contains enough
 information for possible bug matching, with compare of git commit. And
 the bugzilla should have enough information about the fix, like either a
 patch or a link to particular commit. The evolution-related products use
 to it that way.
This would certainly help distributions which want to stay with
Evolution 2.32 for
a while.. My only concern here is, while cherry-picking patches how
would we take
care of the translations and documentation ? Are we adhering to the freezes in
the gnome-2-32 branch (am not calling this a latest stable branch) ?

If the documentation and translations are taken care of, should the
freezes matter ?

- Chenthill.

 That's my opinion.
        Bye,
        Milan

 P.S.: as of today (or tomorrow, if you wish), the official stable
 release is 3.0.0.

 ___
 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 mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Mar 23 - 3:30 PM UTC

2011-03-22 Thread Chenthill Palanisamy
Hi,
 The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates

Check out http://live.gnome.org/Evolution/CommunityMeet for more details.

- Chenthill.
___
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] Sqlite cache for address-book storage in EDS

2011-03-14 Thread Chenthill Palanisamy
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 ?


 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.

- Chenthill.

 ___
 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 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] Branch date?

2011-03-14 Thread Chenthill Palanisamy
On Tue, Mar 15, 2011 at 3:07 AM, Matthew Barnes mbar...@redhat.com wrote:
 It's getting to be branching time again.  I think in the past we've
 usually branched when the hard code freeze starts, which would be next
 Monday.  Shall we go with that again or does anyone have a desire to
 branch sooner?
Am fine with branching on Monday after the hard-code freeze..

- Chenthill.

 (Speaking for myself, I don't really have anything ready to land yet.)

 ___
 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 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] Sqlite cache for address-book storage in EDS

2011-03-13 Thread Chenthill Palanisamy
On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes mbar...@redhat.com wrote:

 On Thu, 2011-03-10 at 08:13 +0100, Milan Crha wrote:
  do not forget that the DB cache is compiled conditionally, because some
  distros do not ship libdb. Using SQLite for this was mentioned months
  ago, only no-one got time to actually do it, so go for it.

 Also, as far as I know there is still licensing issues between Berkeley
 DB's Sleepcat license and [L]GPL, which is how libebackend was born.

 https://bugzilla.gnome.org/show_bug.cgi?id=465374

 I'm +1 on dumping Berkeley DB.


  Only think of two things:
  - using binary storage for this kind of data is bad for cases where
    the binary file breaks, either due to an update/downgrade of the
    library providing access to it, or just by a crash. It's not so hot
    with camel as SQLite has there only summary data, but if you want to
    store also real data in it, then it can be a problem. There are people
    having issues recovering their data from addressbook storage already,
    but if you are going to do any change on it, then it would be good to
    think of that from the beginning. It would be good to store raw vCards
    in some plain text file(s) which will be indexed by SQLite summary.
    This plain text file(s) will be then easy to import to evolution if
    something goes wrong, and with erasing SQLite file user will not
    loose any valuable data. (I'm thinking of a flat maildir approach
    here.)

 Milan raises a good point about binary formats versus text.  Would be
 good for the raw data to remain human readable.
Yes, it makes senses to store it that way. If we can index the data in
sqlite summary and store
VCards in the way we store individual mail data, it should be sufficient..


 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).
I think sqlite should suffice in indexing this..


 We've been talking about moving to notmuch [1] for mail indexing, and
 notmuch is built on Xapian.  Trying out Xapian for address books might
 be a good test drive for using it with mail.
To be honest, I wont be having that much time for testing this for
address-book. Jony
was trying to evaluate the performance between sqlite and notmuch mail indexing
for mails, any updates there Jony ?

- Chenthill.

 The catch is, Xapian is written in C++.  So we'd likely have to hand
 write our own GObject bindings for it in C.  That's what makes it a long
 shot.  But we could look to notmuch even WebKit/GTK+ for examples of
 binding C++ to C.  My C++ is rusty but I still have my Stroustrup text
 book.


 [1] http://notmuchmail.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
___
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] Sqlite cache for address-book storage in EDS

2011-03-09 Thread Chenthill Palanisamy
Hi,
   I was going through the Address-book cache used in EDS while starting to
write the address-book backend for EWS. We use EBookBackendCache that stores
in the form of xml, EBookBackendDBCache which uses libdb for storing the
VCard strings. While EBookBackendSummary stores the information about names,
email ids for faster lookup.

Some backends use EBookBackendCache and some use EBookBackendDBCache.

ldap, google, webdave uses EBookBackendCache.
file, groupwise, exchange uses EBookBackendDBCache.

I was wondering if its worth writing a EBookBackendSqliteCache as we are
already using sqlite for string emails and later migrating all backends to
use the same.  The summary and VCard strings can be stored in a single Cache
without the need for using EBookBackendSummary. Any thoughts ?

- Chenthill.
___
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] [Reminder] Evolution community meeting at #evolution-meet channel - Feb 16 - 3:30 PM UTC

2011-02-14 Thread Chenthill Palanisamy
Hi,
  The meeting goes as follows,

* Project updates
* Discussion on queries/decisions
* Individual updates 

- Chenthill.


___
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] [Reminder] Evolution community meeting at #evolution-meet channel - Feb 16 - 3:30 PM UTC

2011-02-14 Thread Chenthill Palanisamy
On Mon, Feb 14, 2011 at 10:51 PM, Matthew Barnes mbar...@redhat.com wrote:

 On Mon, 2011-02-14 at 21:18 +0530, vikas ruhil wrote:
   can tell in more detail about Meeting ?
   i want to participate in meeting ?
   so please tell ?

 See: http://projects.gnome.org/evolution/meetings.shtml

 We should add some boilerplate text to these meeting announcements that
 includes the above link to the meeting log archives.

Will put in a detailed information in the wiki and add it to the meeting
announcements.



 By the way, Chen, I won't be able to attend this week.  If you or Milan
 could send me the log I'll get it posted.

Sure, will send you.

- Chenthill.
___
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] (no subject)

2011-02-09 Thread Chenthill Palanisamy
On Wed, Feb 9, 2011 at 7:40 PM, thilagaraj thilak
tk.thilaga...@gmail.comwrote:

 sir,
  i'm really interested in studiying linux, but i experienced in
 windows environment.
 sir,please tell me first of all what can i do for got experienced in
 Linux environment with basics.
  sir,unfortunately i joined evolution-hackers in gnome.org.but i can't
 understand what they do and their purposes?,
   i'm doing B.E(cse) fulltime 3rd year.my long day dream in my life
 is to play in linux like windows environment.please please help me to
 achieve my dream as well as my goal.

This is not a right forum to ask about contributing to linux and
understanding linux.
Anyways you can find a lot of sources by just googling. Checkout,

http://live.gnome.org/JoinGnome
http://en.wikipedia.org/wiki/Linux
http://www.linuxforums.org/

I would encourage you to look listinfo and its archives to understand what a
particular mailing-list is
meant for before proceeding with your queries.

- Chenthill.



 Thank you sir!...
 ___
 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 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] evolution documentation

2010-02-01 Thread Chenthill
On Mon, 2010-02-01 at 11:41 -0500, Shreyas Phadnis wrote:
 On Mon, Feb 1, 2010 at 1:35 AM, chen pchenth...@novell.com wrote:
 There is no documentation for imapx yet. You can refer to the
 documentation for camel in www.go-evolution.org it is up to
 date as of
 now. Also feel free to clarify your doubts on irc #evolution
 channel.
 
 
 
 
 Thanks. I will refer to this documentation
  
 Would you be interested in putting some documentation for imapx while
 u
 learn the arch. where I could provide some help ? :)
 
 
 
 Yes, definitely. Why not? I will ping you IRC as I learn more. 
That would be great!!

 
 
 BTW, IMAPX looks very promising. Its much snappier. Of course there
 are occasional crashes (which I have not been able to reproduce
 reliably). I am looking into enabling all the debug settings as I
 explore more..
Have pushed in some fixes. Let me know if they fix the issues. Please
send me the gdb traces or feel free to file a bug in bugzilla.gnome.org.

Thanks, Chenthill.
 
 
  


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


Re: [Evolution-hackers] Moving from the single mbox file format for the local folders

2009-12-15 Thread Chenthill
On Tue, 2009-12-15 at 15:09 -0500, Reid Thompson wrote:
 On Wed, 2009-12-16 at 01:16 +0530, Chenthill wrote:
 
  
  Approach #1,
  migrating local storage from mbox to maildir format. With maildir I
  have
  heard about two issues,
  
  * Not able to create subfolders under INBOX -
  https://bugzilla.gnome.org/show_bug.cgi?id=536240 .
 I hadn't noticed the above, so I guess it's a non-issue for me
 
 What is the second issue?
Sorry missed to mention it here, with maildir we would need to rename
files for unread/read flag changes which can be avoided in the later
approach.

  
  Approach #2,
  Migrate from a single mbox file per folder to mbox per email. Srini
  mentioned an advantage that this would avoid the file renames that
  maildir does. I think this is much like how other remote providers
 in
  evo store the email.
 You still have a filename per email right?
yes.
 What naming convention would be used?
We would be using the uid of the message . uid would be a 32 bit
unsigned integer.

  
  I thought of bring this in this list to gather more opinions to
 choose
  the right one. The approach #2 seems a better one as we are choosing
 a
  way for storing the messages internally in evo. Are we missing to
 see
  anything while we choose the second one ? 
  
  One advantage which I see with #1 is that its a standard way.
 Would Evo provide a mechanism to migrate/convert a mailbox/folder with
 this format to a mailbox/folder with a standard format?
Yes we would provide an UI option for exporting data. While going with
the second approach, I would prefer exporting in maildir format.

 I.E. Currently, dragging a folder in one format to an account in a
 different format performs the proper migration to the new account's
 folder format.
 
 Or would it be up to the user to do something like
 
 for file in `ls *mbox`
 do
movemail $file maildir:///tmp/maildr
 done
 
 if they wanted to migrate to standard format?
It would be the same behavior as before with the mbox-file-per-email if
we choose to do that.

- Chenthill.
  
  Thanks, Chenthill.
 


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


Re: [Evolution-hackers] Camel Manifesto

2009-11-22 Thread Chenthill
.
 
  Additionally, the way Camel current works (even now, with the sqlite
  backend), when a folder is opened, the entire summary for the folder
 is
  loaded the same as it used to be before the sqlite changes. This
 seems
  rather... wasteful? Kinda defeats the purpose of using sqlite (or
 any
  other database backend). The main problem with the older format is
 that
  it did not allow random-access, which means we really needed to load
 the
  whole thing into memory for a number of reasons:
 
 1. each record being a different size requires sequential
 access
  from disk
 2. can't sort by sender, subject, date (or whatever) until you
 have
  the entire summary in memory
 3. doing lookups on message UIDs would be prohibitively slow
 from disk
 
  With a db backend, none of these problems exist any longer. Some
 Camel
  APIs would likely need to change in order to support taking
 advantage of
  this new feature, but it's something that needs to be done.
 
 
 IIRC, For showing in message list, we already fetch only whatever
 records are needed and do not load the full summary onto the memory.
 For instance, if you have selected Unread mail in the QuickShow
 combo box, only unread mails' summary items are loaded.
 
 
  These things seem like much bigger wins for Camel's (and, by
 extension,
  Evolution's) usability/maintainability than making Camel async and
 are
  also far more trivial to implement.
 
  Just some things to think about...
 
 
 I tend to agree with Fejj on this and I am big fan of threads. But I
 no longer work on evo and knowing Matthew  I believe he knows what is
 the best. All the best :-)
We are all part of evolution community :) So would be good not to say,
am not longer working on evo. Sharing opinions/ideas is a big
contribution in it-self :) It helps people who contribute through code
to do the right things. just a humble thought.


- Chenthill.
 


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


[Evolution-hackers] Agenda for the community meeting - Thursday (3:30 PM UTC - 4:30 PM UTC)

2009-11-16 Thread Chenthill
Hi all,
We would be discussing on the following items, 

* go through the blockers
* pending patch reviews
* status updates

Bugs from Akhil listed last week -

 https://bugzilla.gnome.org/show_bug.cgi?id=593700
 [regression] Opens folder on top 

 https://bugzilla.gnome.org/show_bug.cgi?id=597648 
 evolution crashed : moved to calendar

 https://bugzilla.gnome.org/show_bug.cgi?id=601519
 Cannot start evolution-alarm-notify process

 https://bugzilla.gnome.org/show_bug.cgi?id=601525
 e-calendar-factory crashes the second time I start evo

 https://bugzilla.gnome.org/show_bug.cgi?id=596566 
 gtkhtml crash 

 https://bugzilla.gnome.org/show_bug.cgi?id=555262
 evolution and pidgin hangs

 https://bugzilla.gnome.org/show_bug.cgi?id=598769  (MAPI)
 evolution-data-server-2.28 crashed with SIGSEGV in
 find_SPropValue_data()

 https://bugzilla.gnome.org/show_bug.cgi?id=585615  (MAPI)
 Exchange MAPI account setup gets wrong userid in database

 https://bugzilla.gnome.org/show_bug.cgi?id=601484 (MAPI)
 cann't accept a meeting request

 https://bugzilla.gnome.org/show_bug.cgi?id=600560 - MAPI Potential
 blocker Calendar information only up to yesterday

 https://bugzilla.gnome.org/show_bug.cgi?id=601202 (MAPI)
 Evo will delete your addressbook on the server with no warning

This list will be debated and improved moving further.

Pitch inside #evolution-meet (irc.gimpnet.org) irc channel to discuss
and share thoughts with the developers!!

Attached the last weeks meeting logs.

- Chenthill.
chen Lets get started in another minute and have a small discussion to know 
whats happening and moving further with coming releases
mcrha releases, hmm
chen mcrha, yup we have 2.28.1 and 29.1 coming this month
* mcrha was hoping in the upcoming year forecast :)
abharath ;)
chen lol step by step
chen as we all know dbus calendar has been merged now
mcrha yeah, one big step, then few small steps
chen and i would like lakhil to play a major part in bringing the major bugs 
during every meeting
chen and we can share the bugs among us assigning and making sure the issues 
are fixed before the release
lakhil chen, i keep sharing in irc daily ... though i will try to prepare one 
for meeting 
* mcrha noticed flood of those yesterday
chen prolly we can discuss over bugs like 
https://bugzilla.gnome.org/show_bug.cgi?id=557613
chen to ensure they are fixed on time
chen lakhil, bring it to light and discussing it would make sure these go in 
before the release
lakhil yeah, sure 
chen lakhil, would be great if you have a list before us during these 
meetings :)
chen mcrha, and coming on patch reviews,
chen know there are lot of ur patches waiting on the same
mcrha actually, i changes a strategy slightly
chen mcrha, can all the patches which are straight forward or if your 
confident on the fixes be committed directly ?
chen and consult on the fixes where you have some doubt..
mcrha I attach patches for test or review, if reporter can try the patch 
and says ok, then I commit
mcrha chen, yup, i can do that, I was hoping in starting with that on 
January, though
chen mcrha, oh why ?
chen mcrha, prolly you can attach the patch marking it as committed right away
mcrha just for fun of attaching patches to bugzilla.
mcrha does it worth it?
chen mcrha, and the left ones means that they are requiring some review 
comment
chen mcrha, don think so
mcrha 'don' ~~ don't?
chen ok don't :)
mcrha just clarifying a meaning.
mcrha I do not think it worth it too, the commit ID should be enough there
chen mcrha, i would say testing from the reporter is fine, but commit it if 
you feel the approach taken is correct
chen mcrha, agree
mcrha you know the code will be quite different when you allow me to commit 
without asking, right?
chen mcrha, well we have all spent enough time to make a judgement whether 
the approach is right or wrong
chen and of-course having a review is always better, but considering the 
ammount of people we have now
chen we will not be able to follow the same style
mcrha right, that's a bad thing (low human resources)
chen mcrha, so if you have patches,
chen which are on the above category commit them!
chen i mean for the patches right now in the bugzilla as well
* mcrha is wondering how chen means 'if' :)
lakhil :D
abharath :D
* chen leaves the rest to mcrha :)
mcrha patches in bugzilla, I miss the user statistic page there
lakhil mcrha, now it's added back 
abharath haha and lakhil the points page :D
chen lol
lakhil all are back :D
mcrha chen, I'll go the safe side, killing master only
abharath aah :D
abharath mcrha: lol
mcrha lakhil, is the statistics page back?
abharath you the one who has to save the killing :D
chen mcrha, ok, hold it on stable as well by ur judgement
lakhil mcrha, yep 
mcrha lakhil, good, let me look how I stand for past few weeks ;)
chen to update what i have been doing,
mcrha chen, yeah, stable is a different story
lakhil https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html
chen committed the imapx

[Evolution-hackers] evolution 2.28.0 released!!

2009-09-21 Thread Chenthill
Hi all,
   Evolution team is happy and proud to announce the evolution
2.28.0 release. To give an overview of what the release provides,

• Google calendar will be available through Caldav interface by default

• Support for unmatched vfolder and creating vfolder using vfolders is
added back.

• Configurable date formats

• Selecting local ICal files as calendar sources

• Better Calendar cache

• Attachment bar rewrite

• GroupWise conversation threading

• GroupWise meeting retract/resend

• Tons of bug fixes

As many would know already, we branched evolution early in order to get
rid of bonobo. Am happy to see this from mbarnes!

We have already started working on the tasks identified for the 2.30.
Here is the summary of those tasks,

• Bonobo less Evolution

• EDS DBus port

• Exchange MAPI Improvements

• Mailer async operations (with IMAPX)

• GNOME 3.0 Cleanup

• Migrate go-evolution wiki contents to lgo and
gnome.org/projects/evolution

• Quick steps for writing evolution plugins

• Disk summary regressions on vfolder

If you would like to get involved in any of the above mentioned work or
have some new ideas, we would be happy to guide. We need more people
getting involved in Evolution development!

This is a special release for myself and mbarnes as we have taken the
responsibility of maintainer-ship from this release.

Thanks to all the users, testers, developers, translators, bug masters,
distributors and everyone involved in the project.

Thanks, Chenthill.


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


[Evolution-hackers] Evolution branched for GNOME 2.28

2009-08-11 Thread Chenthill
Hi, 
  We have made a early branching for evolution for GNOME 2.28. We have
been discussing on this in the past and to have the context, please go
through the following threads,

http://mail.gnome.org/archives/evolution-hackers/2009-August/msg8.html
and
http://mail.gnome.org/archives/release-team/2009-June/msg00018.html

The following modules have been branched,
gtkhtml, evolution-data-server, evolution and evolution-exchange. The
branch is gnome-2-28.

Only critical fixes will be made for evolution-2.28. By critical fixes,
I mean blockers and important bugs identified as must-fix by module
maintainers. All freezes would apply for gnome-2-28 branch. Please note
that these patches needs to be committed to master and gnome-2-28
branch.

The kill-bonobo-branch and eds-dbus-port will be merged into master. So
it means master will not have any freezes. Most of the active work will
be going on master branch to get it usable for evolution 2.29.1.

Once the branches are merged to trunk, we would be replying back to this
thread mentioning the same.

We have made a rough road-map for Evolution 3.0 -
http://www.go-evolution.org/Evo3.0  which will be discussed and modified
further. 

We will also be discussing over some pending tasks from Evolution 2.28
and include the ones which are possible for
http://www.go-evolution.org/Evo2.28 .


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


[Evolution-hackers] Branching for Evolution 2.28 on Aug 11

2009-08-04 Thread Chenthill
Hi,
  We have been waiting for a while to get the eds address-book dbus port
merged into master for 2.28. Considering the stability issues we have at
the moment with the branch (http://tinyurl.com/bgo-eds-dbus-hybrid ) and
some work which needs to be done for evolution-exchange to work, we will
be merging into master immediately after the branching for 2.28.

Kill-bonobo branch will also get merged and we will have enough time to
work through them for 3.0. We would also be merging the eds calendar
dbus port.

Most of the work will be going on in master to get the ported pieces
stable after branching. So when 2.29.1 comes out on oct 28 with these
changes, we can assure some stability.

Branching for 2.28 will be done on Aug 11th immediately after the UI
freeze/2.27.90 release. I will send out another mail after branching so
that developers ensure the relevant patches are committed to both 2.28
branch and master.

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


Re: [Evolution-hackers] go-evolution.org

2009-07-30 Thread P Chenthill
We had a discussion in yesterday's #evolution-meet about the
go-evolution.org wiki to conclude on things. We have now made a decision
to move the wiki to l.g.o.
The archived contents would be eventually moved to
www.gnome.org/projects/evolution . Time-line for the same is not yet
decided. Until then the contents would remain in go-evolution.org.

Meeting logs -
http://projects.gnome.org/evolution/meeting-logs/2009-07-29.shtml .

Thanks, Chenthill.
On Mon, 2009-07-27 at 17:51 +, Matthew Barnes wrote:
 On Mon, 2009-07-27 at 22:57 +0530, Johnny Jacob wrote:
  http://www.go-evolution.org/Special:Version
  
  Mediawiki :-)
 
 Ah, thanks for that!  Now I can actually conduct some experiments.
 
 Matthew Barnes
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers







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


Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

2009-07-28 Thread Chenthill
On Fri, 2009-07-24 at 20:20 +0200, Patrick Ohly wrote:
 Hello!
 
 Let's pick up this discussion again. When we agree on the API changes,
 then I'll try to follow up with an implementation for the file backend.
 
 On Thu, 2009-01-08 at 13:48 +0100, Patrick Ohly wrote:
  Hello Suman!
  
  I forgot to ask: do you agree in general with the plan to do atomic
  updates via e_book_commit_contact() and e_cal_modify_object() by
  defining the semantic as suggested?
 
 I've come to the conclusion that overloading the old calls is not worth
 the trouble. Therefore I now suggest to add new variants of the call
 because...
 
  I also need to extend the proposal: removing an item has similar race
  conditions (sync starts, user updates item, sync removes item). The
  current APIs for removing items make it harder to pass in the expected
  REV resp. LAST-MODIFIED. The only API call that could do it without
  changing its prototype is e_book_async_remove_contact(EContact
  *contact). e_book_remove_contact(), e_cal_remove_object(),
  e_cal_remove_object_with_mod() all just take ID strings.
 
 ... we need these new variants for the delete operations anyway.
 
 I have not looked at the calendar API yet. Let me know what you think
 about the attached patch for a new ebook API and I will continue with
 calendar next, before implementing anything.
Then changes made are reasonable. Nice api documentation! This can be
done in calendar also. For calendars we use sequence numbers for items
shared with people and last-modified in general.

 
 In this current incarnation the patch tries a bit to provide simple
 implementations of the new calls, but this isn't meant to be complete.
Would be better to get these api's committed after the branching is done
for 2.27.x. We will be merging the eds-addressbook dbus port this week
(for 2.27.x) and the calendar part for evolution 3.0. Will keep you
informed on the same.

- Chenthill.

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


Re: [Evolution-hackers] go-evolution.org

2009-07-23 Thread Chenthill
Am including nirav in the thread. He is working on with the novell IST
to get the required rights. He would be able to provide more details..
  
Thanks, Chenthill.
On Mon, 2009-07-13 at 11:06 +0200, Andre Klapper wrote:
 Am Sonntag, den 12.07.2009, 21:31 -0400 schrieb Matthew Barnes:
  I don't know how feasible this is, but what do you guys think about
  eventually migrating the wiki to live.gnome.org/evolution.
 
 I am all for it.
 
  I have no idea who has admin rights to the wiki
 
 According to Parag Srini has sysop rights.
 
 andre



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


Re: [Evolution-hackers] go-evolution.org

2009-07-23 Thread P Chenthill
On Thu, 2009-07-23 at 07:34 -0400, Matthew Barnes wrote:
 On Thu, 2009-07-23 at 14:35 +0530, Sankar P wrote:
  I don't see a high data content. There are Camel docs, plugin docs,
  some design docs about shell and threading, most of which will have to
  change anyway, soon. And most of the other links originating from the
  go-evolution home page points to obsolete contents. There are some
  test cases, but iirc they are stored in Novell testopia already.
We would still need to maintain the old data to know the history though
they may become obsolete. Certainly a lot of things mentioned still hold
true ;)

 ...snip...
 
  If all these does not convince you, you can save dollars on the
  storage space for the site ;-) . So imho, it is definitely worth
  moving to live.gnome.org .
 
 +1  Well stated.  :)
I concur with this provided all the old data are still maintained.

- Chenthill.

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


Re: [Evolution-hackers] go-evolution.org

2009-07-23 Thread Chenthill
On Thu, 2009-07-23 at 11:09 -0400, Matthew Barnes wrote:
 On Thu, 2009-07-23 at 06:15 -0600, P Chenthill wrote:
  We would still need to maintain the old data to know the history though
  they may become obsolete. Certainly a lot of things mentioned still hold
  true ;)
 
 A compromise might be to only migrate the pages with current and
 accurate information to l.g.o, and keep go-evolution.org around as a
 historical archive.  Archived pages brought back to life at a later date
 could be migrated individually.  It -is- a wiki, after all.
Makes sense. How about putting the architecture and other historic data
on roadmaps into www.gnome.org/projects/evolution and current pages in
l.g.o ?

Close go-evolution.org once for all.

- Chenthill.
 
 Might be interesting to compile a list of pages we still maintain or
 care about.  I have a few not listed on the front page (BugzillaTopics
 and ReleaseHOWTO, for example).
 
 Perhaps a bigger issue is converting the page markup.  I've noticed
 syntactic differences between the two sites [1], but I don't even know
 what wiki software the two sites are using.  Need to see if there's
 markup migration scripts out there.
 
 Matthew Barnes
 
 
 [1] live.gnome.org's markup syntax seems way more expressive and is
 actually DOCUMENTED! (http://live.gnome.org/HelpOnEditing)  Unlike
 our own. (http://www.go-evolution.org/Help:Editing)  Not to mention
 the style sheets are prettier.


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


Re: [Evolution-hackers] Request for upgrading the minimum sqlite version to the latest stable version 3.6.x

2009-07-21 Thread Chenthill
Hi,
   I have been using sqlite-3.6.16 version for around 2 weeks and it
seems to work fine. I have updated the external dependencies page for
gnome 2.27.x with minimum and recommended version of sqlite to be
3.6.16.

The jhbuild moduleset needs to be updated. There is a patch which
modifies configure.ac and configure script to add some options. The
patch for configure script needs to be regenerated for sqlite 3.6.16.

Thanks, Chenthill.
On Wed, 2009-06-03 at 04:43 -0600, Chenthill(P Chenthill) wrote:
 To be more specific 3.6.x = 3.6.14.2 (latest stable version) would be
 better unless there is a reason not to have it as a minimum version.
 
 Thanks, Chenthill.
 On Wed, 2009-06-03 at 15:27 +0530, Chenthill wrote:
  Hi,
 We (evolution team) would like to request upgrading the minimum
  required version for sqlite to 3.6.x from 3.5.9 for the following
  reasons,
  
  1) Api change in xCheckReservedLock method. (reference -
  http://bugzilla.gnome.org/show_bug.cgi?id=575084 )
  2) Most of the distributions have sqlite 3.6
  
  Am adding ddl in CC to see if any other application has any issues with the 
  same.
  
  Thanks, Chenthill.
 


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


Re: [Evolution-hackers] GNOME 3.0 - Evolution plans IRC team meeting

2009-06-24 Thread P Chenthill
I will not be able to attend the irc meeting today. But the following
log has the discussion we had on Wednesday night in the channel. My
opinions are put in there. It would be good if its taken into account
while discussing this in the meeting.


- Chenthill.
On Tue, 2009-06-23 at 22:47 +0530, Srinivasa Ragavan wrote:
 Guys,
 
 We have made some proposals to the release-team on GNOME 3.0 plans for
 Evolution. Specially release/scheduling specifics. Read through the
 thread.
 
 http://mail.gnome.org/archives/release-team/2009-June/msg00018.html
 
 We'll probably workout the exact schedule/decision.
 
 I wanted to discuss this in tomorrow irc team meeting. But due to my
 busy schedule and tight meetings tomorrow, I won't be able to make it,
 and I want to post-pone the team meeting to thursday (UTC 10:00) just
 this time. Sorry, if this is a late notice.
 
 Try to make it or keep me informed if you have some
 suggestions/thoughts. TIA.
 
 -Srini.
 
 
 
 
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers


seb128 srag: hi
seb128 srag: you 2.26 to be 2.28 and 2.27 to be unstable is a very not cool 
idea!
seb128 your 
seb128 srag: it basically means let's screw all those who track GNOME 2.27 
and have already updated to 2.27.n
xkahn !  The final composer addressbook bug seems to be related to whether 
the data has finished loading when you press enter.
* nxvl has quit (leaving)
srag hey seb128 
* cosimoc (~cosi...@jalfrezi.collabora.co.uk) has joined #evolution
xkahn no...  I can't reproduce...
xkahn :(
srag but do you think 2.28 will be stable with eds/dbus port and KB merging? 
or delaying that would stabilize 3.0 ?
* nxvl (~n...@200.106.87.231) has joined #evolution
* tbf__ has quit (Read error: 145 (Connection timed out))
* nxvl has quit (leaving)
srag seb128, but do you think 2.28 will be stable with eds/dbus port and KB 
merging? or delaying that would stabilize 3.0 ?
* You are now known as chen
* nxvl (~n...@200.106.87.231) has joined #evolution
andre if current 2.27.x is stable enough and does not contain dbus-port and 
kill-bonobo it should become 2.28. evo should branch very early (soon) for 
2.29.x and get dbus and kill-bonobo in.
andre but i think that's discussed by the evo team
andre seb128, ^^
chen yes, i would like to see if we can get a window for three major things 
lined up for calendar along with older patches (which I have noted in my 
release machine),
* tbf (~math...@dslb-088-067-108-091.pools.arcor-ip.net) has joined #evolution
chen * cache rewrite - http://www.go-evolution.org/CalendarStore ,
chen Gsoc eds optimization patches and google calendar replaced by caldav at 
the backend 
andre so who maintains the addressbook and can finally review 556061?
srag andre, chen but that leaves master out of testing for quite some time.
chen my other worry is many good patches which inbolves more changes have not 
been taken into trunk. i just heard from mcrha early w.r.t caldav which we need 
to look at..
srag its as simple as merging late.
chen srag, so if these are covered, i have no issues :)
andre srag: well, distros are free to package master for testing
srag chen, the patches ?
andre kill-bonobo is available for fedora
andre ubuntu can also package it
hggdh er
andre er?
chen srag, i have noted some which break freezes, but really good to have. I 
have the list on another system in office. i can mail them across
chen as a reply back to thread..
srag andre, but honestly, people won't use it, unless its the *official* 
version
hggdh andre, yes, I guess we could. But it will be a PPA release, not a main
srag chen, we can take up that.. not a problem.
andre hggdh, sure
srag andre, Im fine to have both 2.27.x and 2.26.x released till 3.0 comes 
out..
chen but have not covered the patches which have not committed in stable. i 
think all individual maintainers have to look at the patches on the components 
to just ensure..
andre srag, encourage people to do so
hggdh srag, the issue is we already delivered 2.27.3 to Karmic, going back 
will be a pain
andre there's blogs and mailing lists.
srag hggdh, if its a matter of version, we can work that out.. cache 
shouldn't be a problem.
srag hggdh, but I understand your issue 
andre that's why i currently also favor making 2.27.x - 2.28.x and branch 
very early (and to be very conservative for 2.27.x for the rest of the time)
srag andre, right, I love that proposal really, but Im afraid, it would miss 
the good amount of testing that can happen if its called 2.27.x :(
hggdh andre, +1
andre srag, what is it?
srag the master branch 
srag Im trying to recall something that happened with gdm, dont know the 
exact releases/numbers
andre archlinux and debian still ship gdm 2.20 in their current unstable
andre i don't think it's that similar though
srag not similar, but would be great, if distros ship 2.27.x and together 
with 2.26.0

Re: [Evolution-hackers] Evolution thoughts for GNOME 3.0

2009-06-20 Thread Chenthill
On Thu, 2009-06-18 at 02:21 +0200, Andre Klapper wrote:
 Am Mittwoch, den 17.06.2009, 23:50 +0530 schrieb Srinivasa Ragavan:
  - Continue Evolution 2.26 as stable series till 3.0 comes out.
  - Treat Evolution 2.28 as a intermediate milestone for GNOME/Evolution
  3.0
  - Continue releasing Evolution 2.26.x  (Evolution 2.26.5/6/7...) series
  as stable releases for GNOME 2.28.1/2/3 instead of releasing Evolution
  2.28.1/2/3.
 
 You might call the stable Evolution releases 2.28.x but create them
 from the gnome-2-26 branch. On the other hand that is confusing if you
 were up to continue calling the unstable series for 3.0 2.27.x.
 So we ship e.g. Evolution 2.26.6/.7 for GNOME 2.28.1/.2?
 
 
 r-t: Having GNOME releases in mind I wonder which release suite an
 Evolution 2.27.13 release would be part of in the last weeks of GNOME
 2.27.x - I don't think we should include a 2.27.13 Evolution release in
 e.g. GNOME 2.27.92. People expect components of a release candidate (two
 weeks before a major release) to be way more stable than Evolution
 2.27.13 at that time (6 months before a major release).
 So how to ensure testing of the continued unstable branch in the last
 weeks before 2.28.0?
 r-t could think of an additional 2.29.0 release (shipping all modules
 that have branched for gnome-3-0 already before 2.28 release) maybe one
 week before 2.28.0?
I somehow miss the last reply from Srini on this thread though I see it
in web. So replying back to this. I like the idea of not branching and
continue to port the code for killing bonobo from eds and evolution.

But we also need to consider some patches which have added API and some
string changes. There might not be many UI changes, but still there
might be some useful ones. I don have the entire list now as we have not
discussed/looked over them yet. I have not yet got the GSoc EDS
optimization patches, but if I can get them over soon and if its good
enough I would love to push them to stable branch along with calendar
cache rewrite (http://www.go-evolution.org/Evo2.28) (quoting one case).

Thinking about the freezes API/ABI/Feature freezes coming along in a
months time. What about branching for gnome-2-27 immediately after that
and starting to merge the kill bonobo stuffs ? This would mean we will
not need to think about the merging important patches with freeze breaks
into stable. So instead of 9 months we would have 8 months.

- Chenthill.
 
  I expect lot of rewrites, dbus port merge, bonobo deprecation (kill
  bonobo merge). etc. I don't think, Evolution 2.28 can be stable, unless
  I postpone these tasks which might merge late in 2.28 cycle to really
  2.29.x.
 [...]
  Thoughts on this? 
 
 After some bad experiences with kill-summary bugs in 2.24.x I agree with
 your proposal to continue 2.27.x for the next 9 months and kind of drop
 2.28.x.
 
  Secondly, Evolution uses GNOME canvas in and around every UI. I wanted
  to know the future direction/migration path, haven't seen one before.
  Its gonna be another painful task like deprecating bonobo with in
  Evolution :/. I would like to vote against this, if there is a
  possibility.
 
 http://bugzilla.gnome.org/show_bug.cgi?id=571742
 
 I still have not found out when and why libgnomecanvas was deprecated by
 the release-team. Maybe someone remembers?
 
 According to http://www.gnome.org/~fpeters/299.html Evolution, planner
 and gthumb use libgnomecanvas.
 
 andre


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


[Evolution-hackers] Request for upgrading the minimum sqlite version to the latest stable version 3.6.x

2009-06-03 Thread Chenthill
Hi,
   We (evolution team) would like to request upgrading the minimum
required version for sqlite to 3.6.x from 3.5.9 for the following
reasons,

1) Api change in xCheckReservedLock method. (reference -
http://bugzilla.gnome.org/show_bug.cgi?id=575084 )
2) Most of the distributions have sqlite 3.6

Am adding ddl in CC to see if any other application has any issues with the 
same.

Thanks, Chenthill.

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


Re: [Evolution-hackers] Request for upgrading the minimum sqlite version to the latest stable version 3.6.x

2009-06-03 Thread P Chenthill
To be more specific 3.6.x = 3.6.14.2 (latest stable version) would be
better unless there is a reason not to have it as a minimum version.

Thanks, Chenthill.
On Wed, 2009-06-03 at 15:27 +0530, Chenthill wrote:
 Hi,
We (evolution team) would like to request upgrading the minimum
 required version for sqlite to 3.6.x from 3.5.9 for the following
 reasons,
 
 1) Api change in xCheckReservedLock method. (reference -
 http://bugzilla.gnome.org/show_bug.cgi?id=575084 )
 2) Most of the distributions have sqlite 3.6
 
 Am adding ddl in CC to see if any other application has any issues with the 
 same.
 
 Thanks, Chenthill.


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


Re: [Evolution-hackers] Coding style

2009-06-01 Thread P Chenthill
On Mon, 2009-06-01 at 16:13 +0100, Ross Burton wrote:
 Hi,
 
 Whilst working on the merge of eds-dbus I noticed again that the coding
 styles in e-d-s are really mixed up.   What is the official coding style
 (mainly indent size and tabs/spaces)?
You find the official coding-style at
http://projects.gnome.org/evolution/patch.shtml 

I should admit that we have not followed strictly.

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


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


Re: [Evolution-hackers] libgdata

2009-02-22 Thread Chenthill
On Sun, 2009-02-22 at 22:44 +, Philip Withnall wrote:
 Hi,
 
 I've been writing a full C library to access GData-based services, with
 the aims of:
 
 1. rewriting Totem's YouTube plugin in C,
 2. providing a useful desktop-wide way to access Google services, and
 3. merging it with the libgdata and libgdata-google in e-d-s' tree, such
 that e-d-s depends on a proper, external library for its Google Calendar
 server backend.
 
 I'm getting to the stage where it would be possible to merge with the
 code in e-d-s' libgdata, but obviously this can only happen if the
 authors of e-d-s' libgdata agree and think this is a good idea. If you
 want to keep your libgdata separate and untouched, I'm happy to go along
 with that, although it seems like a missed opportunity as regards
 reducing code duplication across the desktop.
 
 The code is currently on Github[1], with the beginnings of Google
 Calendar support in a branch[2], but the eventual aim is to move it to
 GNOME SVN (or git, or whatever) and move it into the desktop platform.
EDS provides data primarily for mail,contacts, calendar, memos and
tasks. It would be good to move the libgdata code from EDS into a
separate project, say 'gdata-c' in order provide entire set of Google
services. You can probably create a new project in svn.gnome.org for the
same.

- Chenthill.
 
 Regards,
 Philip Withnall
 
 [1]: http://github.com/pwithnall/libgdata/tree/master
 [2]: http://github.com/pwithnall/libgdata/tree/calendar
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

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


Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

2009-01-08 Thread Chenthill
 capability for e_cal_get_static_capability() and
 e_book_check_static_capabilities().
 
 Any comments?
With respect to the e_cal_remove* API, it would be good to have last
modified time specified in it. It would then require a new API to be
added..

thanks, Chenthill.

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


Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-10-06 Thread Chenthill
I was not able to try the upstream libical yet. I am right now packed
with some other work, so I will try to get this done as soon as
possible.  Suddenly the weekends have gone out of my hands as I have to
move out of station to places that do not have internet connectivity.
Either me or suman will make the changes and get the work done for
2.25.1 if the time is sufficient to get libical as a external dependency
for GNOME 2.25.1. We would test the library and let you know before oct
17th.

thanks, Chenthill.
On Fri, 2008-09-19 at 14:41 +0530, Chenthill wrote:
 On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote:
   I have applied Chenthill's memory management patches (only to the 
   'libical' directory and to the examples -- still have to do the 
   'libicalcap' and 'libicalss' directories) using function names ending in 
   _r.  
   IMHO, HANDLE_LIBICAL_MEMORY can be removed.
 
  
  Ok folks, it's done ...
  
  The remaining portions of libical (libicalcap and libicalss) have been 
  converted to the _r API.   (The test suite still uses the old API and 
  will continue to do so for a while.)
  
  Now is the time for Evolution code to be updated to use the new calling 
  syntax.
  
  Is there anything we can do to facilitate this, or should we just hang 
  out and wait for you folks to kick the tires on the new library?  Let me 
  know...
 I will make the changes and test it over this weekend.
 
 thanks, Chenthill.
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

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


Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-19 Thread Chenthill
On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote:
  I have applied Chenthill's memory management patches (only to the 
  'libical' directory and to the examples -- still have to do the 
  'libicalcap' and 'libicalss' directories) using function names ending in 
  _r.  
  IMHO, HANDLE_LIBICAL_MEMORY can be removed.

 
 Ok folks, it's done ...
 
 The remaining portions of libical (libicalcap and libicalss) have been 
 converted to the _r API.   (The test suite still uses the old API and 
 will continue to do so for a while.)
 
 Now is the time for Evolution code to be updated to use the new calling 
 syntax.
 
 Is there anything we can do to facilitate this, or should we just hang 
 out and wait for you folks to kick the tires on the new library?  Let me 
 know...
I will make the changes and test it over this weekend.

thanks, Chenthill.

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


Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-10 Thread Chenthill
On Tue, 2008-09-09 at 18:00 +0200, Patrick Ohly wrote:
 On Tue, 2008-09-09 at 09:12 -0400, IGnatius T Foobar wrote:
  Chenthill wrote:
   So it is better to inform all the stake holders about the change and let
   them depend on the library versions to decide whether to free the memory
   or not if they have a need to depend on the older versions of libical. I
   think no one deny to make the necessary changes knowing that the old API
   is not very stable.
  
   Atleast once I noticed the problem. I made this patch and made all the
   changes required in evolution, evolution-exchange and
   evolution-data-server. I would not really like to change them again with
   new APIS :)
  Although I agree that the new memory model is a vast improvement over 
  the existing one, I think you may be underestimating the potential 
  effects of telling dozens of downstream projects that they will have to 
  rewrite their code *right* *now* in order to continue using libical.  
  Many will respond by forking, or staying forked, which as I mentioned 
  earlier is exactly the opposite of what we are trying to accomplish.
 
 I agree.
When I started writing the patch, since only the gnome packages which
depend on libecal are going be affected. I thought of incorporating
changes in all other modules myself since it was just to grep all the
apis and free the returned memory.

So I had a thinking that all the downstream projects would be ready to
change their code during a release time since stability is an issue and
change can be done fast. But if it was not the case and might result in
forking again, the only solution which I too see is create a new set of
API's which uses the new memory allocation.

 
  How would you feel about a global flag which tells libical how to 
  allocate memory?
 
 The problem with that is that it is not possible to mix code which uses
 the old and the new semantic. For example, a program or library which
 uses libical directly, using the old semantic, couldn't be combined with
 the Evolution libraries.

Yes right. Its not possible to have the old semantic with changed memory
allocation. 
 
 To let old and new code coexists I would suggest the following approach:
  1. The Evolution patch gets applied, making the core functions safe
 to use.
  2. The function implementations whose semantic has changed get
 renamed; I kind of like the _r suffix, but _alloc or _copy would
 also work.
  3. Under the old names small wrappers are added which establish the
 old behavior again by copying the string into the ring buffer
 and freeing the dynamically allocated one: this incurs some
 overhead, but usage of these versions of the calls is
 discouraged anyway. By using function attributes it would be
 possible to trigger deprecation warnings for code which still
 uses them.
  4. In the header file both variants are declared.
  5. In addition, ical.h also redefines the old names to the new
 names if the HANDLE_LIBICAL_MEMORY define is set: Evolution code
 already does that and therefore continues to work with such a
 modified upstream libical without source code changes.
 
 I personally would prefer to avoid step 5 and rather do a search/replace
 in Evolution, but Chenthill didn't like that.
Since we do really want to remove the fork and pick up packages from
upstream, I can change the apis in evolution related packages if a new
set of apis with some suffix is provided from libical upstream.

The old patch is attached with bug 516408. You can find the patches at,

http://svn.gnome.org/viewvc/libical?view=revisionrevision=633 
and 
http://svn.gnome.org/viewvc/libical?view=revisionrevision=637


thanks, Chenthill.

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


Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-09 Thread Chenthill


On Mon, 2008-09-08 at 23:55 -0400, IGnatius T Foobar wrote:
 Patrick Ohly wrote:
  In the upstream libical certain functions return char * pointers into
  memory stored in ring buffers. The caller must not free those pointers.
  The drawback is that the life time of those strings is not predictable.
 
  In the current Evolution libical, those same functions (not renamed!)
  return copies of the string which the caller has to free. Code which was
  written using the old semantic of the calls will leak memory. Code
  adapted to the new semantic (like Evolution) will crash when combined
  with the upstream libical without the same patch.

 Ok, I definitely see the benefit there.   This is similar to POSIX calls 
 which now offer alternative versions (usually with _r appended to the 
 name) that don't use a static buffer or a ring buffer, in order to be 
 reentrant?
  If all users of the upstream libical are willing to adapt their code,
  then the best solution would be to simply import the Evolution patch
  into upstream.

 As much as I'd like to see that happen, I don't think it's realistic.  
 libical is used by dozens of downstream projects, and a sudden forced 
 API change is likely to encourage them to fork (or stay forked, if 
 they've already done so) -- exactly the opposite of the end we are 
 trying to achieve!
  If there is resistance against that, then we could provide two versions
  of each of these API calls: one with the old name and old behavior and
  one with the new behavior and a name suffix. 
 That seems more realistic.  The alternative might be to offer a global 
 flag that tells libical to behave one way or the other?  (I think 
 something like that was suggested at some point.)
 
 While I definitely think the new method of memory allocation makes far 
 more sense (we'll definitely use it in Citadel, as all of our code is 
 multithreaded) -- expecting the entire community to perform a flag day 
 API change in lockstep is likely to cause confusion and delay.   If we 
 pursued either the alternate function names or the global flag, is there 
 likely to be any pushback from the Evolution team?
I do not feel having alternate function names would be a better
solution.

Consider the following API which remains the same before and after the
memory fixes,
char * icalcomponent_as_ical_string (icalcomponent *icomp);

The returned memory from this API was internally handled by libical
before and now its given to the caller. Though the return type gives an
indication that the memory is owned by caller, it was not the case. So
having a new API for this and changing the behavior does not look to be
a good solution since the underlying memory allocation had to be
changed.

Similarly even with other APIs which return const char* values, the
memory can be overwritten at any time. While removing the ring buffer
return type's of all the APIs had to be changed from const char * to
char *. Is it really worth it to have the old unstable APIs which can
crash the application randomly ? My answer would be NO.

This is not just a problem with multi-threaded programs. The crash could
happen once the ring buffer gets full and starts overwriting the used
memory.

Since we statically link to libical and expose it via libecal, we have
updated the library versions of libecal. We have an additional flag
check (hack) also for it now with a warning as in
http://bugzilla.gnome.org/show_bug.cgi?id=528986 .


So it is better to inform all the stake holders about the change and let
them depend on the library versions to decide whether to free the memory
or not if they have a need to depend on the older versions of libical. I
think no one deny to make the necessary changes knowing that the old API
is not very stable.

Atleast once I noticed the problem. I made this patch and made all the
changes required in evolution, evolution-exchange and
evolution-data-server. I would not really like to change them again with
new APIS :)


thanks, Chenthill.

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


Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-08 Thread Chenthill
On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:
 Hello!
 
 http://sourceforge.net/projects/freeassociation/ has released 0.32 of
 libical on 2008-09-01. The KDE-PIM team has switched to that code for
 KDE 4.2.
 
 On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
  On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: 
   I discovered last week that there is an attempt to resurrect libical
   from non-maintainership, merge all of the patches from various forks,
   and start making sane releases again[1].  Are the evolution team as
   whole interested in merging their changes to libical upstream and
   depending on it to be installed when a release is made with all of the
   relevant changes?  libical isn't exactly a small library, and statically
   linking it is a waste of memory for everyone.
 
  I vaguely recall the biggest diff being timezone handling.
 
 Not sure about that. They have merged the system timezone database
 conversion code, if that's what you mean. Unfortunately they missed the
 recent bug fixes required for that code to handle the upcoming
 summer-winter time transition. We really should have been more active
 with keeping them informed about Evolution-libical changes. I have
 alerted them and the KDE-PIM team of the problem.
 
 However, they haven't included the modified memory handling. Considering
 that this breaks the user space API merging it might be a hard sell.
 
   I'll happily start working on extracting the changes to EDS and pushing
   them into the new libical repository, if the Evolution team as a whole
   agrees that the fork of libical will be dropped.
 
 +1
+1 from my side too. We were discussing about this at
http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes
to be merged upstream. We wanted to get this done for 2.26.

thanks, Chenthill.

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


Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-08 Thread Chenthill
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote:
 Chenthill wrote: 
  On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:

   Hello!
   
   http://sourceforge.net/projects/freeassociation/ has released 0.32 of
   libical on 2008-09-01. The KDE-PIM team has switched to that code for
   KDE 4.2.
   
   On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
   
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: 
  
 I discovered last week that there is an attempt to resurrect libical
 from non-maintainership, merge all of the patches from various forks,
 and start making sane releases again[1].  Are the evolution team as
 whole interested in merging their changes to libical upstream and
 depending on it to be installed when a release is made with all of the
 relevant changes?  libical isn't exactly a small library, and 
 statically
 linking it is a waste of memory for everyone.
 
I vaguely recall the biggest diff being timezone handling.
  
   Not sure about that. They have merged the system timezone database
   conversion code, if that's what you mean. Unfortunately they missed the
   recent bug fixes required for that code to handle the upcoming
   summer-winter time transition. We really should have been more active
   with keeping them informed about Evolution-libical changes. I have
   alerted them and the KDE-PIM team of the problem.
   
   However, they haven't included the modified memory handling. Considering
   that this breaks the user space API merging it might be a hard sell.
   
   
 I'll happily start working on extracting the changes to EDS and 
 pushing
 them into the new libical repository, if the Evolution team as a whole
 agrees that the fork of libical will be dropped.
 
   +1
   
  +1 from my side too. We were discussing about this at
  http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes
  to be merged upstream. We wanted to get this done for 2.26.
  
  thanks, Chenthill
 In what way does it break the userspace API?   Is it possible that the
 API could be extended in such a way that memory handling depends upon
 how it's called?
All the information/discussion about this is available at,
http://bugzilla.gnome.org/show_bug.cgi?id=516408
and
http://bugzilla.gnome.org/show_bug.cgi?id=528986
 
 We would *really* like to get everyone merged and re-unify this
 library once and for all.  Everyone would benefit.
We provide our support too to get this done!!


thanks, Chenthill.

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


Re: [Evolution-hackers] bug fixing in stable 2.22.x branch

2008-09-02 Thread Chenthill
Patrick,

On Mon, 2008-09-01 at 19:55 +0200, Patrick Ohly wrote:
 On Thu, 2008-08-21 at 12:37 +0530, Chenthill wrote:
  Thanks, I will send out a mail to the list mentioning the critical
  fixes which have gone in recently in the stable branch which needs to be
  taken into the distro's.
 
There is one additional fix which I would recommend for timezones, 
http://svn.gnome.org/viewvc/libical?view=revisionrevision=645 . 

- Chenthill.

 Bug #548268 is in trunk (thanks Chenthill!) and tested automatically
 now. The test showed that the time zones in South America and Australia
 were also affected.
 
 I think we should send out that bug list to the distributors ASAP.
 Debian Etch is already frozen. Chenthill, do you have the list ready and
 can you send it both to this list and the distributor list?
 
 My own proposal for inclusion are
   * 548268: time zone conversion incorrect
   * 546934: [Exchange Connector] contact change tracking is broken
 (required by SyncEvolution)
   * 499932: [Bug 499932] Not deleting from e-mail server after specified 
 time
 

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


Re: [Evolution-hackers] camel-db-summary changes merged to Trunk

2008-07-16 Thread Chenthill
This is great!! I am updating the code now and will test it out :-)


- Chenthill.
On Thu, 2008-07-17 at 00:03 +0530, Sankar wrote:
 Hi ,
 
 As many of you know, Srini and I were working on a branch
 camel-db-summary (codenamed Madagascar).
 
 This is now merged with trunk. Please see
 http://svn.gnome.org/viewvc/evolution-data-server?view=revisionrevision=9125 
 
 This adds a new dependency on sqlite. So, you need to have sqlite devel
 packages installed. 
 
 You will have to update evolution and evolution-exchange packages as
 well.
 
 As of now, evolution-exchange has some crashers connecting with the
 exchange servers. 
 
 Some of the quick-show items like (recent messages) does not work. 
 
 Meta summary code is wiped out and hence new mails are not beagle
 searcheable.
 
 But, we promise we will fix them soon :-)
 
 
 Any other feedback or issues, that you get, please ping us in
 #evolution. 
 
 I will be sending out a detailed description of what we have done and
 what is pending, soon.
 
 Thanks.
 
 --
 Sankar
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

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


Re: [Evolution-hackers] time zone problem: extending API instable branch?

2008-06-12 Thread P Chenthill
Hi Srini,
  The patches are available at comment #4. The two new files 
e-cal-check-timezones.[ch] which adds new API's.

- Chenthill.
 Srinivasa Ragavan [EMAIL PROTECTED] 06/13/08 8:44 AM 
Patrick,

Can you just point us to the right patch, that extends API ? I seem to
hit the wrong patch. I dont see any .h changes also. 

Is there a way, we can work around for stable branch alone? We may need
release team approval, if we have to update API (I guess so, though EDS
isn't part of platform, we may have to atleast check with them)

-Srini.

On Thu, 2008-06-12 at 22:25 +0200, Patrick Ohly wrote:
 Hello,
 
 the patch that I am suggesting to fix the time zone issues in Evolution
 (see http://bugzilla.gnome.org/show_bug.cgi?id=528902) adds new
 functions to libecal. Note that the extended library is backwards
 compatible, i.e., this is not an API change which requires recompiling
 other programs (http://bugzilla.gnome.org/attachment.cgi?id=112638).
 
 Is this an acceptable solution for the 2.22.x stable branch? Chentill
 reviewed the patch and agreed to committing it on trunk after some minor
 changes (which I have done in the meantime), but he is concerned about
 the API and rather would like to keep this out of the stable release.
 
 I'm writing here to also get the opinion of Evolution packagers who
 might not monitor the discussion taking place in the bug tracker. Is
 this issue important enough to extend the API in the next 2.22.x
 release? If Evolution upstream doesn't include it in 2.22.x, are
 distributions going to apply the patch (it is written against the stable
 branch and applies cleanly) anyway?
 
 I personally think that this is important because Evolution will
 continue to use out-dated time zone definitions for new meetings in
 perpetuity unless people wipe out their old calendars or the patch is
 applied. Quoting Paul Smith, who missed a meeting this spring due to
 this bug:
 I have to add my voice to those saying please, please, PLEASE
 someone fix this complete and utter disaster!
 

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

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


Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-16 Thread chenthill palanisamy
On Tue, 2008-04-15 at 18:07 +0200, Patrick Ohly wrote:
 On Tue, 2008-04-15 at 13:59 +0530, chenthill wrote: 
  To preserve the timezone history, the best way would be to store the old
  rules in VTIMEZONES which should be done in libical.
 
 If I understand you correctly, you are suggesting to merge a VTIMEZONE
 with TZID=FOO that comes with a new meeting invitation with a previously
 stored VTIMEZONE with the same TZID, so that the merged VTIMEZONE has
 the rules from both the original VTIMEZONE.
 
 The problem is that incoming VTIMEZONE definitions from Exchange do not
 contain information to which year the rules apply. In the examples that
 I quoted, both use DTSTART:16010101T02 and thus are mutually
 exclusive.
Nope I don't mean merging here. The VTIMEZONE from libical currently do
not provide the history of timezone changes (older + current rrules) for
the system timezones. Libical should be modified so that the VTIMEZONE's
generated stores the timezone history. The Tzfile would have the history
stored on the system, libical just does not store it in VTIMEZONE.


Say if a meeting is received from exchange server with some Tzid for
America/New_York. As we discussed below, this needs to be mapped to
system timezone and libical should provide the VTIMEZONE which has the
timezone history.  This way, we need not use the VTIMEZONE sent by
exchange and still display the older/current events properly.

 
  I do not recommend having another set of tzid's with
  versions in it for maintaining the old rules. This would trigger the
  comparison of rules between different versions of timezones.
 
 I don't get this part. Can you elaborate what you mean? Are you saying
 that storing a VTIMEZONE with TZID=FOO as TZID=FOO 2 when it conflicts
 with an existing VTIMEZONE should be avoided?
yes, if  libical is modified to return VTIMEZONE with the history and
once mapping between foreign timezones to system timezones is done at
the backend, this is would not be required. All the older events would
be properly displayed.

 
   Once the
  outlook timezones are mapped with libical ones, the libical timezones
  which would have the old rules can be used.
 
 Mapping foreign TZIDs to system timezones always should be attempted
 first. Storing a VTIMEZONE under a different name is only the fallback.
 
   [VTIMEZONE and VEVENT are added separately]
I don't think it works like that. iirc the whole VCALENDAR (used as
top-level component in itip-formatter) which has events and timezone
gets passed to the backend, the backend adds the timezone and events to
the cache, notifies the UI.
   
   After looking at the Evolution source code I already came to the same
   conclusion. However, clients like SyncEvolution do add VTIMEZONE and
   VEVENT separately. That is necessary because the UID of each new VEVENT
   is required immediately, which is not possible (or at least very
   awkward) via ecal_receive_objects().
  I hope SyncEvolution is the only backend which does it in this way.
 
 SyncEvolution is not a backend. It is a client program using the
 synchronous libecal API.
Ah ok. I misunderstood that it has a corresponding external backend as
well.

 
 I believe OpenSync works the same way, although I haven't looked at it
 during the last two years.
 
   I am
  not sure if we would need a libecal API for this. Is it not possible to
  handle it inside e_cal_backend_add_timezone?
 
 No, because the call cannot return the information to which TZID the
 timezone was mapped. Modifying the icaltimezone *zone would be an API
 change.
The tzid need not be changed for the VEVENT. The following would work
fine even if VTIMEZONE and VEVENT are handled separately,

e_cal_backend_add_timezone - Add the timezone to backend's cache if the
timezone cannot be matched with the system timezone else do not add.

e_cal_backend_get_timezone - use the mapping and provide proper system
timezone or if its unable to map, it needs to get the timezone from the
cache.

The clients can now use the corresponding libecal API's to get the right
timezone. So, I feel this can be done commonly to all backends at EDS.

 
  Yeah you can get the code after two weeks, not a problem. Please file a
  bug on this since the old bug is about, outdated evolution timezones
  which is obsolete now as we pickup the timezones from the system. The
  bug also has a too many comments already. Probably we can also schedule
  a meeting on irc and have a discussion on this. Please let me know the
  time which would be suitable for you.
 
 I'll create a new bug report. Should we move the discussion away from
 this list?

I think if we discuss this on IRC, we can conclude on the design
faster. It would be better to do the patch reviews in bugzilla.

 
 Usually we could meet on IRC during the evening CEST, but there's not
 much time this week.
I may not be available over next week. Let me know a suitable time
during this week or after April 28th.

- Chenthill

Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-15 Thread chenthill
On Fri, 2008-04-11 at 23:31 +0200, Patrick Ohly wrote:
 On Fri, 2008-04-11 at 00:55 -0600, P Chenthill wrote:
 [Exchange calendar backend patch]
  In cases of exchange the old VTIMEZONE and the new VTIMEZONE would have
  the same tzid, only the rules would be different. All events old and new
  will just use the latest timezone from the backend since they would have
  the same tzid in their start/end dates.
 
 And that would be wrong for the old events which are truly in the past.
 Consider the 2006 example that I sent: when viewing the year 2006 in the
 calendar, the system timezone definition is used and thus Evolution
 correctly uses the summer saving rules from 2006. Using the updated
 VTIMEZONE for events in that year would lead to a one hour shift during
 those weeks where old and new rules differ.
 
 It's arguably the lesser evil for recurring events because the current,
 still relevant recurrences would be displayed correctly, so there is
 some value in it. But for old events which are archived for reference
 purposes it would be just wrong. What I am suggesting would solve this
 problem by preserving both the old and the new VTIMEZONE.
 
 For recurring events the mapping to the more complex system timezone
 definitions helps.
To preserve the timezone history, the best way would be to store the old
rules in VTIMEZONES which should be done in libical. Since exchange does
not like it, the older rules should be stripped off while sending the
timezones to the exchange server at the backend and libical should
facilitate this. I do not recommend having another set of tzid's with
versions in it for maintaining the old rules. This would trigger the
comparison of rules between different versions of timezones. Once the
outlook timezones are mapped with libical ones, the libical timezones
which would have the old rules can be used.

 
 [VTIMEZONE and VEVENT are added separately]
  I don't think it works like that. iirc the whole VCALENDAR (used as
  top-level component in itip-formatter) which has events and timezone
  gets passed to the backend, the backend adds the timezone and events to
  the cache, notifies the UI.
 
 After looking at the Evolution source code I already came to the same
 conclusion. However, clients like SyncEvolution do add VTIMEZONE and
 VEVENT separately. That is necessary because the UID of each new VEVENT
 is required immediately, which is not possible (or at least very
 awkward) via ecal_receive_objects().
I hope SyncEvolution is the only backend which does it in this way. I am
not sure if we would need a libecal API for this. Is it not possible to
handle it inside e_cal_backend_add_timezone ? I don't know much about
how SyncEvolution handles it. While considering with all the other
backend's in mind which are under EDS, exchange, I don't feel the need.

 
 This makes the new function a bit more compleyoutube.com/TuxSkyNetx, but I 
 still think it is
 doable to come up with a solution which can be used by backends and
 clients. Attached is a proposal. In SyncEvolution I would lookup
 existing VTIMEZONE in the calendar via the e_cal_tzlookup_ecal() utility
 function, which then uses e_cal_get_timezone(). 
   
 I checked the code of the file backend. The e_cal_check_timezone() call
 would fit right before the icalcomponent_merge_component() call and
 would use the other tzlookup function which checks against local
 VTIMEZONE components.
 
 All the other backends would have to be adapted in a similar way. I
 considered modifying the general e_cal_backend_file_receive_objects(),
 but decided against it because individual backends might have better
 ways of dealing with the problem. I also don't want to touch code which
 I cannot test.
 
 I will be out of town for three days. If there are no objections, then
 I'll try to get working code together when I come back, hopefully before
 I go on a business trip for two weeks the week after. Time, anyone got
 some time?
Yeah you can get the code after two weeks, not a problem. Please file a
bug on this since the old bug is about, outdated evolution timezones
which is obsolete now as we pickup the timezones from the system. The
bug also has a too many comments already. Probably we can also schedule
a meeting on irc and have a discussion on this. Please let me know the
time which would be suitable for you.

thanks, Chenthill.

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


Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-11 Thread P Chenthill
On Wed, 2008-04-09 at 00:42 +0200, Patrick Ohly wrote:
 On Mo, 2008-04-07 at 23:40 -0600, P Chenthill wrote:
  On Thu, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote:
   One could argue that the sending program is at fault: it could have used
   a different TZID after changing the timezone definition. Alternatively
   it could have sent a more complex VTIMEZONE which also includes the
   historic rules. I believe both causes other problems in practice.
   Speculating about it is futile anyway and won't change the meeting
   invitations that Evolution has to deal with.
   
   Besides, don't blame Outlook too much: Evolution = 1.12 now does
   exactly the same thing. For example, a meeting invitation now uses
   /softwarestudio.org/Tzfile/America/Los_Angeles and only includes the
   current rules for daylight saving transitions.
  It just includes the current rules for outlook compatibility.
 
 Yep, that's the I believe both causes other problems in practice
 part ;-)

 
  I am just back after a small vacation.
 
 Ah, that explains the silence. I'll be away over the weekend and Monday
 myself and don't know whether I'll have time before I came back.
 
  I dont think anyone is work on this issue currently. I made a patch for
  exchange backend for solving this issue long time back. But
  unfortunately its not committed in trunk.
 
 Why? Technical issues that I should be aware of?
I think it was postponed to commit after some freeze and missed later. I don 
remember
the exact reasons. I am sure, its not due to any technical reasons :-)


   It uses a timestamp in the
  VTIMEZONE file to store the latest one always. By this way we would also
  know the last time period when the timezone has been changed for that
  location.
 
 I can't claim to understand the patch or the code that it applies to.
 When you say that only the latest VTIMEZONE is stored, that implies that
 only one is stored, right? How does that solve the problem of having an
 event in the calendar which depends on an old revision of the VTIMEZONE
 and another one which needs the current revision?
The cache would have only one version of the timezone at any point since
the tzid is used as a uid for the VTIMEZONE components for storing them.
The X-EVOLUTION-TZ-TIMESTAMP would be used to ensure that only the
latest VTIMEZONE is stored. Since the UI would pick the timezone from
the backend, it would get the right timezone.

In cases of exchange the old VTIMEZONE and the new VTIMEZONE would have
the same tzid, only the rules would be different. All events old and new
will just use the latest timezone from the backend since they would have
the same tzid in their start/end dates.

 
  I am ok with handling using the sequence numbers. I am not sure whether
  a new libecal API would be needed to solve this, since the timezones
  would be handled at the backend.
 
 The client adds the VTIMEZONE and some time later the corresponding
 event. At that time the backend won't be able to correlate the two, but
 that is necessary to change the TZID in the event if the VTIMEZONE was
 stored with a different TZID. Only the client can do that.
I don't think it works like that. iirc the whole VCALENDAR (used as
top-level component in itip-formatter) which has events and timezone
gets passed to the backend, the backend adds the timezone and events to
the cache, notifies the UI. This is the same behavior while accepting
and importing events. Another reason why this has to be handled in
backend is, there can be cases when the user can accept events using
some other client and receive the events through the respective
backends. So handling it in the backend would be better. Atleast above
is the behavior w.r.t exchange, and other backends under EDS.

 
  It would be better to handle all the timezones in a common place inside
  EDS. The reason for that is, same timezones can exist in multiple
  calendars which could not be matched to either system timezone or
  through the fuzzy logic. Currently it is handled separately for every
  calendar and the same information is stored redundantly. Another issue
  which should be taken care of is, the system timezones should not be
  stored in the cache. They should always be taken from the libical
  builtin timezone. Please consider these too while implementing the
  solution.
 
 That's way beyond what I have time for, sorry. Besides, I want to keep
 my changes as small as possible to increase the chance of getting them
 into the stable branch.

- Chenthill.


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


Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-07 Thread P Chenthill
 be a better solution.

 Before I proceed, let me ask: are there other plans to tackle the
 problem? Is someone working on it? Similar questions in #301363 were not
 answered.
 
 Do you agree with the outlined plan in principle? If no-one else is
 working on it and you agree, then I would describe the new API call in
 more detail and see whether I can get it implemented. I would reuse the
 same code in SyncEvolution in order to improve the situation with older
 Evolution releases and to avoid depending on an extended libecal in the
 binary releases.
I am just back after a small vacation.

I dont think anyone is work on this issue currently. I made a patch for
exchange backend for solving this issue long time back. But
unfortunately its not committed in trunk. It uses a timestamp in the
VTIMEZONE file to store the latest one always. By this way we would also
know the last time period when the timezone has been changed for that
location. Have attached the patch for a reference.

I am ok with handling using the sequence numbers. I am not sure whether
a new libecal API would be needed to solve this, since the timezones
would be handled at the backend. Overall I can understand the approach
and it seems good.

It would be better to handle all the timezones in a common place inside
EDS. The reason for that is, same timezones can exist in multiple
calendars which could not be matched to either system timezone or
through the fuzzy logic. Currently it is handled separately for every
calendar and the same information is stored redundantly. Another issue
which should be taken care of is, the system timezones should not be
stored in the cache. They should always be taken from the libical
builtin timezone. Please consider these too while implementing the
solution.

 
 What is the timeline for this? 2.22 is released; if this version is
 picked up by distributions unpatched, then we are bound to run into the
 same problems again end of 2008 and probably also 2009.
If there are no interface changes, we can definitely take the patch in
for stable branch. Please come up with the initial design and once the
patch is ready, we can also look at requesting for a freeze break to get
the patch in for the stable branch also.

- Chenthill.

Index: calendar/e-cal-backend-exchange.c
===
--- calendar/e-cal-backend-exchange.c   (revision 1330)
+++ calendar/e-cal-backend-exchange.c   (working copy)
@@ -1094,6 +1094,27 @@
return priv-default_timezone;
 }
 
+static icaltimetype 
+get_timestamp_from_tzcomp (icalcomponent *icalcomp)
+{
+   icalproperty *icalprop;
+   icaltimetype dtstamp = icaltime_null_time ();   
+
+   for (icalprop = icalcomponent_get_first_property (icalcomp, 
ICAL_X_PROPERTY); icalprop != NULL;
+   icalprop = icalcomponent_get_next_property (icalcomp, 
ICAL_X_PROPERTY)) {
+   const char *name = icalproperty_get_x_name (icalprop);
+
+   if (name  g_str_equal (name, X-EVOLUTION-TZ-TIMESTAMP)) {
+   const char *value = icalproperty_get_x (icalprop);
+   dtstamp = icaltime_from_string (value);
+   break;
+   }
+   }
+
+   return dtstamp;
+}
+
+
 ECalBackendSyncStatus
 e_cal_backend_exchange_add_timezone (ECalBackendExchange *cbex,
 icalcomponent *vtzcomp)
@@ -1109,9 +1130,19 @@
return GNOME_Evolution_Calendar_InvalidObject;
tzid = icalproperty_get_tzid (prop);
d(printf(ecbe_add_timezone: tzid = %s\n, tzid));
-   if (g_hash_table_lookup (cbex-priv-timezones, tzid))
-   return GNOME_Evolution_Calendar_ObjectIdAlreadyExists;
+   if ((zone = g_hash_table_lookup (cbex-priv-timezones, tzid))) {
+   icalcomponent *tzcomp_old;
+   icaltimetype dtstamp_old, dtstamp_new;
 
+   tzcomp_old = icaltimezone_get_component (zone);
+   
+   dtstamp_old = get_timestamp_from_tzcomp (tzcomp_old);
+   dtstamp_new = get_timestamp_from_tzcomp (vtzcomp);
+
+   if (icaltime_is_null_time (dtstamp_new) || 
(!icaltime_is_null_time (dtstamp_old)  icaltime_compare (dtstamp_new, 
dtstamp_old) = 0))
+   return GNOME_Evolution_Calendar_ObjectIdAlreadyExists;
+   }
+
zone = icaltimezone_new ();
if (!icaltimezone_set_component (zone, icalcomponent_new_clone 
(vtzcomp))) {
icaltimezone_free (zone, TRUE);
Index: calendar/e-cal-backend-exchange-calendar.c
===
--- calendar/e-cal-backend-exchange-calendar.c  (revision 1330)
+++ calendar/e-cal-backend-exchange-calendar.c  (working copy)
@@ -65,12 +65,25 @@
 static void update_x_properties (ECalBackendExchange *cbex, ECalComponent 
*comp);
 
 static void
-add_timezones_from_comp (ECalBackendExchange *cbex

Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-07 Thread P Chenthill
 be a better solution.

 Before I proceed, let me ask: are there other plans to tackle the
 problem? Is someone working on it? Similar questions in #301363 were not
 answered.
 
 Do you agree with the outlined plan in principle? If no-one else is
 working on it and you agree, then I would describe the new API call in
 more detail and see whether I can get it implemented. I would reuse the
 same code in SyncEvolution in order to improve the situation with older
 Evolution releases and to avoid depending on an extended libecal in the
 binary releases.
I am just back after a small vacation.

I dont think anyone is work on this issue currently. I made a patch for
exchange backend for solving this issue long time back. But
unfortunately its not committed in trunk. It uses a timestamp in the
VTIMEZONE file to store the latest one always. By this way we would also
know the last time period when the timezone has been changed for that
location. Have attached the patch for a reference.

I am ok with handling using the sequence numbers. I am not sure whether
a new libecal API would be needed to solve this, since the timezones
would be handled at the backend. Overall I can understand the approach
and it seems good.

It would be better to handle all the timezones in a common place inside
EDS. The reason for that is, same timezones can exist in multiple
calendars which could not be matched to either system timezone or
through the fuzzy logic. Currently it is handled separately for every
calendar and the same information is stored redundantly. Another issue
which should be taken care of is, the system timezones should not be
stored in the cache. They should always be taken from the libical
builtin timezone. Please consider these too while implementing the
solution.

 
 What is the timeline for this? 2.22 is released; if this version is
 picked up by distributions unpatched, then we are bound to run into the
 same problems again end of 2008 and probably also 2009.
If there are no interface changes, we can definitely take the patch in
for stable branch. Please come up with the initial design and once the
patch is ready, we can also look at requesting for a freeze break to get
the patch in for the stable branch also.

- Chenthill.

Index: calendar/e-cal-backend-exchange.c
===
--- calendar/e-cal-backend-exchange.c   (revision 1330)
+++ calendar/e-cal-backend-exchange.c   (working copy)
@@ -1094,6 +1094,27 @@
return priv-default_timezone;
 }
 
+static icaltimetype 
+get_timestamp_from_tzcomp (icalcomponent *icalcomp)
+{
+   icalproperty *icalprop;
+   icaltimetype dtstamp = icaltime_null_time ();   
+
+   for (icalprop = icalcomponent_get_first_property (icalcomp, 
ICAL_X_PROPERTY); icalprop != NULL;
+   icalprop = icalcomponent_get_next_property (icalcomp, 
ICAL_X_PROPERTY)) {
+   const char *name = icalproperty_get_x_name (icalprop);
+
+   if (name  g_str_equal (name, X-EVOLUTION-TZ-TIMESTAMP)) {
+   const char *value = icalproperty_get_x (icalprop);
+   dtstamp = icaltime_from_string (value);
+   break;
+   }
+   }
+
+   return dtstamp;
+}
+
+
 ECalBackendSyncStatus
 e_cal_backend_exchange_add_timezone (ECalBackendExchange *cbex,
 icalcomponent *vtzcomp)
@@ -1109,9 +1130,19 @@
return GNOME_Evolution_Calendar_InvalidObject;
tzid = icalproperty_get_tzid (prop);
d(printf(ecbe_add_timezone: tzid = %s\n, tzid));
-   if (g_hash_table_lookup (cbex-priv-timezones, tzid))
-   return GNOME_Evolution_Calendar_ObjectIdAlreadyExists;
+   if ((zone = g_hash_table_lookup (cbex-priv-timezones, tzid))) {
+   icalcomponent *tzcomp_old;
+   icaltimetype dtstamp_old, dtstamp_new;
 
+   tzcomp_old = icaltimezone_get_component (zone);
+   
+   dtstamp_old = get_timestamp_from_tzcomp (tzcomp_old);
+   dtstamp_new = get_timestamp_from_tzcomp (vtzcomp);
+
+   if (icaltime_is_null_time (dtstamp_new) || 
(!icaltime_is_null_time (dtstamp_old)  icaltime_compare (dtstamp_new, 
dtstamp_old) = 0))
+   return GNOME_Evolution_Calendar_ObjectIdAlreadyExists;
+   }
+
zone = icaltimezone_new ();
if (!icaltimezone_set_component (zone, icalcomponent_new_clone 
(vtzcomp))) {
icaltimezone_free (zone, TRUE);
Index: calendar/e-cal-backend-exchange-calendar.c
===
--- calendar/e-cal-backend-exchange-calendar.c  (revision 1330)
+++ calendar/e-cal-backend-exchange-calendar.c  (working copy)
@@ -65,12 +65,25 @@
 static void update_x_properties (ECalBackendExchange *cbex, ECalComponent 
*comp);
 
 static void
-add_timezones_from_comp (ECalBackendExchange *cbex

Re: [Evolution-hackers] Ical (WebDAV) Web-Calendar read-only!?

2007-11-30 Thread chenthill
Hi Arthur,
On Fri, 2007-11-30 at 11:31 +0100, Artur Mücke wrote:
 Hi,
 
 does anyone know if there is a plan when web-calendars will be
 implemented as writable in Evolution?
 
 I am asking because I want to use Evolution as client for my OpenXchange
 Server that is working with iCal-Calendars. Unfortunately OpenXchange
 doesnt have any CalDAV implementation so I am kind of dependent to the
 ical-support.
 
 Does anyone know if/when iCal calendars will be writable in Evolution!?
It should not be a very big effort to make the web-calendars writable.
If someone is ready to work on it, I can guide them. If someone takes it
up, prolly we can have in the evolution-2.22 release (next major
release) itself.

-Chenthill.
 
 Would be glad about some answers.
 
 Cheers,
 
 Artur
 

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


Re: [Evolution-hackers] Call for Release Notes

2007-08-30 Thread Chenthill
On Mon, 2007-08-27 at 10:01 +, Srinivasa Ragavan wrote:
* System Timezone Integration 
   
   Does this mean that evolution no longer asks the user for their
 timezone
   at first use? Are there any other user-noticeable changes? 
Currently evolution maintains its own timezone files. For every change
in the zonefino, we would need to update the timezone's maintained. Now
with the system timezone integration, we pickup the timezones from the
system, this update from evolution is not required. Evolution would pick
the latest timezone's from the system. There are no user-noticeable
changes.


- Chenthill.

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


Re: [Evolution-hackers] comma-separation of event CATEGORIES

2007-07-10 Thread Chenthill
Hi Patrick,
On Sun, 2007-06-24 at 18:28 +0200, Patrick Ohly wrote:
 Hello,
 
 I got a report that SyncEvolution does not handle CATEGORIES correctly
 in ical 2.0 events when multiple categories are specified. It turned out
 that Evolution or more likely, libical, import/export such events with
 the comma separator escaped like this:
   CATEGORIES:Anniversary\,Holiday
 
 RFC 2445 specifies CATEGORIES with a normal comma as separator and gives
 this example:
   CATEGORIES:APPOINTMENT,EDUCATION
 
 When importing such an event, Evolution stores it with two different
 category properties and then only uses the later one in the GUI:
   CATEGORIES:APPOINTMENT
   CATEGORIES:EDUCATION
 
 At first glance there doesn't seem to be an open bug related to this; it
 still happens with Evolution 2.10. I will open a bug and investigate
 further, but let me bring up some points here first:
   * I suppose right now Evolution continues to use its own libical.
 Are there plans to synchronize with upstream (whathever that is
 at the moment)?
Evolution-2.10 uses the libical from the stable branch. Evolution-2.12
would use the libical from svn HEAD. Evolution does not own a separate
libical.
   * Any bug fix for this should be backwards compatible and treat \,
 just like a normal comma because all existing .ics files will
 continue to contain \, and I would like to add a hack to
 SyncEvolution which converts between \, and , to work around the
 issue in existing Evolution versions.

The bug is in libical and any fix made there would be done so that its
backward compatible.

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


Re: [Evolution-hackers] Calendar Maintainership

2007-05-31 Thread P Chenthill
On Thu, 2007-05-31 at 10:32 +, Srinivasa Ragavan wrote:
 Hi friends,
 
 It is with immense pleasure I announce that Christian Kellner joins
 Chenthill as Calendar Maintainer. He is popularly known as gicmo on
 IRC. Gicmo is already the maintainer of gnome-vfs. He is the author and
 the maintainer of evolution-scalix and the CalDAV provider for
 Evolution.
 
 Welcome on board Gicmo !!!

Welcome Gicmo !!! I am happy to share my responsibilities with you. Let
us discuss and capture our future plans in go-evolution.org.

- Chenthill.

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


Re: [Evolution-hackers] Question about Groupwise and Memos (see bug 389668)

2007-02-21 Thread chenthill
Hi nathan,  
I added the summary and start date fields looking at the
supported fields for the VJOURNAL component. I have not observed the
initial discussions which had happened in the e-hackers list. I feel its
better to have a start field  so that the notes can be sorted well and
would be really useful to know when a note was created. The summary
field can be made optional depending on the backend's needs. I really
did not want to write another backend or a component for just supporting
the summary field in addition to what the memos component intially
supported. The UI changes can be probably taken up for evolution-2.12.

thanks, Chenthill.
On Sat, 2007-02-10 at 09:39 -0800, Nathan Owens wrote:
 Back when the Groupwise functionality was implement for the Memos component, 
 the summary and
 start date fields were added to the Memos GUI. I was wondering why this is 
 done.
 
 IMO, Memos shouldn't have a start date, or a summary. In fact, when I 
 originally implemented the
 component, the Summary field was just a cut-off portion of the Description. 
 It was done
 on-the-fly, and only because I wanted a portion of the Description to show up 
 in the Memos
 component table view. Showing the Description field in the Memos component 
 table didn't look very
 good.

 Adding the summary field has now caused this bug:
 http://bugzilla.gnome.org/show_bug.cgi?id=389668.
 
 As for the Start Date - the memos component isn't meant to be a Journal. It 
 only uses the VJOURNAL
 format because I didn't want to write a new backend (and at the time, the 
 consensus on the
 evolution-hackers list was that VJOURNAL would be appropriate). If we want a 
 true journal, then we
 need a new component. Memos are just little notes (think of the Notes feature 
 in Outlook, or the
 Memos feature in PalmOS - the PalmOS feature is what made me create the Memos 
 component in the
 first place).
 Here's my proposal that I'd like to get feedback on:
 - Remove the Summary and Start Date fields from the GUI
 - Start Date is never set (could always be set to 0, but I don't believe I 
 needed to do that when
 Memos was first implemented)
 - The summary field is automatically filled in (on-the-fly, or whenever the 
 Description gets
 updated) based on the Description.

 I don't know much about GW, but I believe the core code should not support 
 the Date and Summary
 fields as they are currently supported. If we need something different for 
 GW, then it should be
 implemented differently.
 
 Any thoughts? Anyone have insight into the Groupwise changes and why they 
 were made?


 
 Thanks,
 Nathan Owens
 
 
 
 
 
 
  
 
 Don't get soaked.  Take a quick peak at the forecast
 with the Yahoo! Search weather shortcut.
 http://tools.search.yahoo.com/shortcuts/#loc_weather
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

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


Re: [Evolution-hackers] Recurrence ID?

2006-10-17 Thread chenthill
Hi Jules,
  The format of the recurrence id (datetime value) is the same as
that is specified in rfc 2445.

thanks, Chenthill.
On Fri, 2006-10-13 at 14:49 +0200, Jules Colding wrote:
 Hi,
 
 What is the format of the recurrence ID (const char *rid) as used in
 get_object(), remove_object() and other related calendar methods?
 
 Thanks,
   jules
 
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

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


Re: [Evolution-hackers] Converting vevent components into one vcalendar component

2006-08-09 Thread chenthill
Hi teresa,
You can probably create a toplevel VCALENDAR component using
e_cal_util_new_top_level () and add the VEVENT components to it using
icalcomponent_add_component. Hope this answers your question.


- Chenthill.
On Wed, 2006-08-09 at 15:44 -0400, Teresa Thomas wrote:
 I intend to use the function 
 void icalcomponent_merge_component(icalcomponent* comp, icalcomponent*
 comp_to_merge); 
 to merge two VCALENDAR components.
 
 When I query for all the objects in an Evo cal, what I get is a list
 of icalcomponent. I want to convert this bunch of VEVENT
 icalcomponents into a single VCALENDAR icalcomponent so that I can use
 the above mentioned function. Ofcourse, I could convert them into
 strings first and manually concatenate the objects, but is there a
 better way to do this? 
 
 Thanks!
 
 Teresa

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


Re: [Evolution-hackers] Obtaining all events from Evo Cal

2006-08-08 Thread chenthill
Hi Teresa,
Send the query as #t.

- Chenthill.

On Tue, 2006-08-08 at 18:14 -0400, Teresa Thomas wrote:
 Hi
 How can I obtain all the events existing in an ECal. I tried using the
 function:
 gbooleane_cal_get_object_list   (
 ECal *ecal,
  const char *query,
  GList **objects,
  GError **error);
 with a  and  NULL as parameter for query, but it returns a 0 on both
 occassions. 
 
 Thanks in advance!
 
 Teresa

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


Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync

2006-07-31 Thread chenthill
Hi peter,
   You would need to implement both. The ECalBackendSync class has a
sync lock, which is used if the backend can handle only one operation at
a time. It provides the results immediately to the caller.

ECalBackend class provides notifications to the client from EDS.
Please go through http://www.go-evolution.org/EDS_Architecture for more
details.

On Mon, 2006-07-31 at 03:08 -0400, Peter Colijn wrote:
 Suppose I am writing a new calendar backend. Which of these two
 interfaces is preferred? If I implement ECalBackendSync, will
 operations on the calendar cause the UI to block?
It depends on how client is designed.


- Chenthill.


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


Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync

2006-07-31 Thread chenthill
Are you writing a new backend similar to file/http/groupwise ? If so you
can implement the virtual methods extending from ECalBackendSync class.
You can prolly refer to any of the existing backends or
evolution-exchange/calendar.

thanks, Chenthill.

On Mon, 2006-07-31 at 04:22 -0400, Peter Colijn wrote:
 Hi Chenthill,
 
 On 7/31/06, chenthill [EMAIL PROTECTED] wrote:
 You would need to implement both. The ECalBackendSync class has a
  sync lock, which is used if the backend can handle only one operation at
  a time. It provides the results immediately to the caller.
  ECalBackend class provides notifications to the client from EDS.
  Please go through http://www.go-evolution.org/EDS_Architecture for more
  details.
 
 On that page, it says To write a calendar/tasks backend, a subclass
 of ECalBackend (for asynchronous) _OR_ ECalBackendSync (for
 synchronous) needs to be written. (emphasis mine)
 
 If both need to be implemented, perhaps that article should be
 updated? I can see how I could implement EBackendSync, then implement
 EBackend on top of that by having a worker thread that calls the
 EBackendSync calls. Is that what you're referring to?
 
  It depends on how client is designed.
 
 Well, my intended client is Evolution :P With Evolution as the client,
 if I implement ECalBackendSync, will the UI block? Harish mentioned
 that I could avoid having the UI block if I had a separate thread for
 repainting. But if I'm just adding a new calendar backend, and I want
 to use it from Evolution, am I writing any code to do redrawing, etc?
 I certainly hope not!
 
 Thanks!
 
 Peter

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


Re: [Evolution-hackers] ESourceGroup from ESource

2006-07-20 Thread chenthill palanisamy
On Wed, 2006-07-19 at 18:09 -0700, Scott Herscher wrote:
 How does one derive an ESourceGroup from an ESource?  If I call 
 e_source_peek_group() with a valid ESource instance, and then immediately 
 call E_IS_SOURCE_GROUP(), I am getting false.
 
Was the ESource got from ESourceList ? If so, ESourceList object should
be alive while accessing the ESource, otherwise ESourceGroup would be
NULL if the corresponding ESourceGroup was not ref'ed.

- Chenthill.


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


Re: [Evolution-hackers] libecal functions

2006-07-20 Thread chenthill palanisamy
On Wed, 2006-07-19 at 11:25 -0400, Teresa Thomas wrote:
 Hi
 I have one last (hopefully) question about libecal. I want to add a
 VEVENT to an existing Evolution calendar. 
 
 Hence, I created an iCalComponenent to be added and hope to use the
 e_cal_create_object(ECal* eCal,iCalComponent iCalcomp, char** uid,
 char** error) function. 
 
 Now, I understand that eCal is a calendar client. If I want to add my
 event to an Evolution calendar, what exactly should eCal contain? Is
 it some sort of an identity of a cal? If so, how can I obtain it.
ECal client can be obtained by using the function e_cal_new, by passing
an ESource. ESource holds the settings required for a calendar client
which is stored in gconf. The client is associated with the backend
through the protocol specified in the uri stored in ESource. 
Eg: uri starting with file:/// would refer to file backend, contacts://
would be pointing to contacts backend.

- Chenthill.

 
 Thanks! 
 On 7/19/06, Teresa Thomas [EMAIL PROTECTED] wrote:
 Thanks Mr Palanisamy!
 
 My Bad, I actually meant to ask about the function
 e_cal_component_new() in ECalComponent.h/c. 
 Anyway, from what I understand it returns an  ECalComponent,
 which is an (easier to manipulate) wrapper around an
 iCalComponent.
 
 
 
 On 7/19/06, chenthill palanisamy [EMAIL PROTECTED]
 wrote:
 On Tue, 2006-07-18 at 17:44 -0400, Teresa Thomas
 wrote:
  Need some assistance in my quest to comprehend EDS.
 
  What exactly is the difference between
 e_cal_create_object() [in
  ECalComponent] and e_cal_create_object() [in
 ECal ] ? 
 e_cal_create_object is used to create a appointment,
 task or a memo
 object (ECalComponent) in the corresponding backend
 (file, http,
 groupwise etc).  There is no function named
 e_cal_create_object in
 ECalComponent. There is a function
 e_cal_component_get_created which 
 gives the creation date of a ECalComponent.
 
 Please have a look at
 http://www.go-evolution.org/EDS_Architecture .
 
 
 - Chenthill.
 
 
 
 
 

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


Re: [Evolution-hackers] libecal functions

2006-07-19 Thread chenthill palanisamy
On Tue, 2006-07-18 at 17:44 -0400, Teresa Thomas wrote:
 Need some assistance in my quest to comprehend EDS.
 
 What exactly is the difference between e_cal_create_object() [in
 ECalComponent] and e_cal_create_object() [in ECal ] ?
e_cal_create_object is used to create a appointment, task or a memo
object (ECalComponent) in the corresponding backend (file, http,
groupwise etc).  There is no function named e_cal_create_object in
ECalComponent. There is a function e_cal_component_get_created which
gives the creation date of a ECalComponent.
 
Please have a look at http://www.go-evolution.org/EDS_Architecture .


- Chenthill.
 

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


Re: [Evolution-hackers] Exposing Evo calendar events

2006-07-19 Thread chenthill palanisamy
On Sun, 2006-07-16 at 16:24 -0400, Teresa Thomas wrote:
 Thanks Andre, I have been looking at that EDS architecture details but
 it just gives a general picture. 
 
 I am having starting troubles with EDS. Just so I can get started,
 does anyone have any sample code that exposes the events/tasks of an
 evo calendar? 
Have a look at the clock applet code which queries the events/tasks from
EDS and shows it.
http://cvs.gnome.org/viewcvs/gnome-panel/applets/clock/

or the alarm daemon which queries for the events that has alarms for the
current day.
http://cvs.gnome.org/viewcvs/evolution/calendar/gui/alarm-notify/

cheers, chenthill.

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


Re: [Evolution-hackers] ECalComponentAttendee and ECalComponentOrganizer - an invitation to memory leaks?

2006-06-16 Thread Chenthill
Hi Jules,

On Wed, 2006-06-07 at 14:41 +0200, Jules Colding wrote:
 Hi,
 
 Several members of the above mentioned structures are of the 'const char
 *' type. One such member is 'value'.
 
 The message from the API designer, when declaring something 'const char
 *', is commonly that the memory management of that parameter/member is
 the responsibility of whoever allocated the memory.
Yes, the memory for the members such as value is managed inside the
ECalComponent itself. The caller need not allocate the memory.
 
 The usage of ECalComponentAttendee and ECalComponentOrganizer data
 structures in e-d-s is, OTOH, that they are given to some ECalComponent
 and are never touched by the callee again (unless I am totally wrong
 here).
 
 So should data for e.g. the 'value' member be g_strdup'ed to 'value' (as
 does the Groupwise calendar backend) contrary to the expectation that
 the callee should manage the memory for that member?
Groupwise backend does it wrongly which needs to be fixed. Thanks for
pointing it out.


thanks, Chenthill.

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


Re: [Evolution-hackers] What 'role' should a resource-type cutype have?

2006-06-16 Thread Chenthill
Hi Jules,
On Thu, 2006-06-08 at 13:15 +0200, Jules Colding wrote:
 Hi, 
 
 I can't decide upon the ICAL role that a ECalComponentAttendee should
 have if cutype is a resource. I am currently doing:
 
   attendee-cutype = ICAL_CUTYPE_RESOURCE;
   attendee-role = ICAL_ROLE_NONPARTICIPANT; // what else?
 
 Is that the best thing to do? - Thoughts?
yes, AFAIK the resource would be a non-participant.

thanks, Chenthill.
 
 
 Thanks,
   jules
 
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

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


Re: [Evolution-hackers] When do open_sync() gets called from a calendar backend?

2006-05-06 Thread Chenthill
Hi Jules,
Once the mode and timezone is set, e_cal_open_async would be called to
open the calendar. Please check if e_cal_open_async is being called from
evolution. You need not invoke it separately.

thanks, Chenthill.

On Fri, 2006-05-05 at 14:05 +0200, Jules Colding wrote:
 Hi,
 
 I am a bit mystified, due to my lack of intellectual resources, about
 the behavior of my calendar backend.
 
 I have created the gconf source for the calendar and are trying to get
 Evolution to call open_sync() on it, but that never happens. Instead I
 am seeing set_mode_sync() and set_default_timezone_sync() being invoked
 (in that order).
 
 The next thing to happen is that Evolution tells me that it is unable to
 open the calendar.
 
 Do I have to invoke open_sync() myself at some appropriate time? 
 
 
 Thanks,
   jules
 
 BTW: I have invoked e_cal_backend_sync_set_lock(backend, TRUE) in
 e_cal_backend_brutus_init() to force serialization of method
 invocations. 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

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