Re: [Evolution-hackers] evolution-kolab: Lifting the veil

2010-07-09 Thread Christian Hilberg
Hi there,

On Thursday 08 July 2010 at 19:01:25 Matthew Barnes wrote:
 [...]
 Certainly aim for hosting your project on git.gnome.org, but I'd still
 prefer it be split into a separate evolution-kolab repository similar to
 evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm
 told).

Our present status is that we set up the project as a standalone plugin. This 
way, development will be easier for us to handle. If there is no objection 
from Evo developers' side, we will make this decision permanent.

 It just keeps things more modular and it keeps us honest: our
 public APIs -have- to be complete since external projects don't have
 access to private in-tree APIs.  The separation is not meant to be a
 barrier between you and us, just an implementation detail.

So far, we do not see this separation as a barrier. Lets hope this holds true 
in future as well. ;-)

 The process for obtaining a gnome.org account is here:
 [...]

Thanks for the explanation. We'll get back to that later on, when there is 
something sensible ready to be pushed into the repo.

Greetings,

Christian


-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
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: local cache for offline-work

2010-07-09 Thread chen
On Thu, 2010-07-08 at 15:50 +0200, Christian Hilberg wrote:
 Hi all,
 
 in evolution-kolab, we need to provide full offline capabilities for working 
 with Kolab 2 groupware data in offline mode.
 
 Evo 2.30 has an offline mode which works for IMAP email. If I understood 
 correctly, email handling resides within Evolution presently [1], not E-D-S. 
 For our plugin, though, we need to place email stuff in the backend (for 
 handling contact data and calendar data, as these are stored in XML 
 attachments to emails within Kolab 2 context).
 
 This means we will need to sync emails (with proper conflict resolution) when 
 re-connecting to the Kolab server which hold calendar data and contact data. 
 What's more, we have a multimaster-situation here.
 
 As Matthew already pointed out in [2], this is sort of new terrain we're 
 stepping on. In order to get an idea about how much work it will be to 
 implement this feature, I'd like to know whether there are ideas already 
 concerning caching calendar data and address data this way. Alas, I have not 
 found time yet to dig into existing backends to check whether they do caching 
 already or whether there is any infrastructure provided with Evo/EDS 2.30 
 which we could use for that matter.
 
 We'll be happy to receive any pointers into existing plugins where something 
 like this is already done or to discussions about the issue.
Let me try to summarize some pointers for calendar and you could do the
same for address-book as well,
+ Create New ECalBackend for Kolab
+ Use the camel apis to fetch the calendar folder
+ Using the CamelFolder, get its contents. You would mime data and you
can use the Camel libraries again to parse these contents.
+ Convert the Xml calendar data into Ics format and store it into the
backend

So this helps for displaying the contents. Now with creating
meetings/appointments. iirc you would need to send them via smtp ?
+ use the camel_transport apis (look through e_cal_backend_save/send
api's)

There are many backend implementations already available file, exchange,
groupwise etc. and you can refer them.. I would recommend looking
through groupwise/exchange and shoot your questions if any..

Since no one has yet tried using camel apis, we do not know if there are
any issues while you might face. But we should be able to help you while
you progress..

The same holds good for address-book also.

Thanks, Chenthill.
 
 Thanks in advance,
 
   Christian
 
 
 [1] http://mail.gnome.org/archives/evolution-hackers/2010-June/msg00018.html
 [2] http://mail.gnome.org/archives/evolution-hackers/2010-June/msg00022.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 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: local cache for offline-work

2010-07-09 Thread Christian Hilberg
On Thursday 08 July 2010 at 15:50:19 Christian Hilberg wrote:
 Hi all,
 in evolution-kolab, we need to provide full offline capabilities for
 working with Kolab 2 groupware data in offline mode.

Anything? Anyone? :-)

Best regards,

Christian

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
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: Lifting the veil

2010-07-09 Thread chen
On Thu, 2010-07-08 at 13:01 -0400, Matthew Barnes wrote:
 On Thu, 2010-07-08 at 16:01 +0100, Michael Meeks wrote:
   If Evolution staff will be willing to host our project sources within
   Evo git repo, we'll happily transfer our stuff there as soon as we
   have a first preview ready.
  
  Perhaps something to dicuss on #evolution (irc.gimp.net) - but it'd be
  great to have you working in the same git repo IMHO [ not that it's my
  decision of course - I defer to Matthew/Chen etc. ;-]
 
 
 Certainly aim for hosting your project on git.gnome.org, but I'd still
 prefer it be split into a separate evolution-kolab repository similar to
 evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm
 told).  It just keeps things more modular and it keeps us honest: our
 public APIs -have- to be complete since external projects don't have
 access to private in-tree APIs.  The separation is not meant to be a
 barrier between you and us, just an implementation detail.
While thinking about this, I just got a thought of why not a,
evolution-collab-backends package which can hold all the eds
collborative backends (that provides mail+calendar+address-book) such as
mapi, exchange, groupwise with sufficient configuration options to
choose what to compile ? This would help in making the api changes to
all backends and keep external backends connected. 

I support maintaining the backend code in a separate package though. Its
easier to provide updates to the backends if its not part of eds
at-least with some distros (at-least with suse as I use it).

- Chenthill.
 
 The process for obtaining a gnome.org account is here:
 
 http://live.gnome.org/NewAccounts
 
 Each of your developers should apply for their own account, but I would
 suggest waiting to do this until after you have a working public beta,
 as you'll have more credibility to the gnome.org admins then (which is
 not us!).
 
 Once you have your gnome.org accounts, you can clone your git repository
 on git.gnome.org by following the procedure here:
 
 http://live.gnome.org/Git/NewRepository
 
 Hope this helps.
 
 
 ___
 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-kolab: Lifting the veil

2010-07-09 Thread Sankar P
 On 7/9/2010 at 09:44 PM, in message 
 1278692045.6831.33.ca...@linux-e1q4.site,
chen pchenth...@novell.com wrote: 
 On Thu, 2010-07-08 at 13:01 -0400, Matthew Barnes wrote:
  On Thu, 2010-07-08 at 16:01 +0100, Michael Meeks wrote:
If Evolution staff will be willing to host our project sources within
Evo git repo, we'll happily transfer our stuff there as soon as we
have a first preview ready.
   
 Perhaps something to dicuss on #evolution (irc.gimp.net) - but it'd be
   great to have you working in the same git repo IMHO [ not that it's my
   decision of course - I defer to Matthew/Chen etc. ;-]
  
  
  Certainly aim for hosting your project on git.gnome.org, but I'd still
  prefer it be split into a separate evolution-kolab repository similar to
  evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm
  told).  It just keeps things more modular and it keeps us honest: our
  public APIs -have- to be complete since external projects don't have
  access to private in-tree APIs.  The separation is not meant to be a
  barrier between you and us, just an implementation detail.
 While thinking about this, I just got a thought of why not a,
 evolution-collab-backends package which can hold all the eds
 collborative backends (that provides mail+calendar+address-book) such as
 mapi, exchange, groupwise with sufficient configuration options to
 choose what to compile ? This would help in making the api changes to
 all backends and keep external backends connected. 
 
 I support maintaining the backend code in a separate package though. Its
 easier to provide updates to the backends if its not part of eds
 at-least with some distros (at-least with suse as I use it).



More modules translate to more problems trying to build things. Oh I need to 
git clone another 10 modules. In my opinion, we should just follow linux kernel 
filesystems style (all under one tree). There can be any number of backends, 
but we can use sane config options to build only interested backends (for 
instance someone working on RHT may not bother about GW etc.) But for someone 
who wants to build evo with all backends, it is just one 'git clone' that he 
needs to do. 

Also, during release time, more modules contribute to more work for the 
maintainer(s).  Changes made in core may not reflect in some low priority 
backends, if they are kept out of the tree. (oh that out-of-tree Scalix backend 
is still using flat-file-summary-APIs-oh-wait-lets-ignore-it etc. types)

However,  I am a little out of touch with the things and so I trust 
Chen/Matthew 's decisions as they know the current state. Just my 2 cents. 

Sankar
 
 - Chenthill.
  
  The process for obtaining a gnome.org account is here:
  
  http://live.gnome.org/NewAccounts 
  
  Each of your developers should apply for their own account, but I would
  suggest waiting to do this until after you have a working public beta,
  as you'll have more credibility to the gnome.org admins then (which is
  not us!).
  
  Once you have your gnome.org accounts, you can clone your git repository
  on git.gnome.org by following the procedure here:
  
  http://live.gnome.org/Git/NewRepository 
  
  Hope this helps.
  
  
  ___
  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


Re: [Evolution-hackers] evolution-kolab: local cache for offline-work

2010-07-09 Thread Christian Hilberg
On Friday 09 July 2010 at 18:01:53 chen wrote:
 [...]
 Let me try to summarize some pointers for calendar and you could do the
 same for address-book as well,
 + Create New ECalBackend for Kolab
 + Use the camel apis to fetch the calendar folder
 + Using the CamelFolder, get its contents. You would mime data and you
 can use the Camel libraries again to parse these contents.
 + Convert the Xml calendar data into Ics format and store it into the
 backend

Yeah, this much is clear. There will be a fully-fledged two-way lossless 
conversion between EDS data types and Kolab2 data types, and the conversion 
will most probably be done on-the-fly (if we run into performance issues here, 
we might change plans... :).

 So this helps for displaying the contents. Now with creating
 meetings/appointments. iirc you would need to send them via smtp ?
 + use the camel_transport apis (look through e_cal_backend_save/send
 api's)

Also no worries so far.

Let me be a little more specific (I should have been right away, but my mails 
tend to become lengthy...):

* We need to create a local cache for emails which is handled by the plugin 
backend(s).

* Does there exist any infrastructure in E-D-S which will help us creating a 
local email cache via IMAP?

* Orelse, is there a sensible way to re-use existing caching functionality 
inside our backend which comes from Evolution, since Email handling resides 
there, presently? Without weaving knots between Evo and E-D-S which will be 
prone to failure and unclean, I mean?


 There are many backend implementations already available file, exchange,
 groupwise etc. and you can refer them.. I would recommend looking
 through groupwise/exchange and shoot your questions if any..

I'm in the process of having a closer look at them...

 Since no one has yet tried using camel apis, we do not know if there are
 any issues while you might face. But we should be able to help you while
 you progress..

Okay, thanks.

Once I'M really clear that we have to do these things fully on our own and we 
cannot re-use existing infrastructure, I will instantly stop harassing you 
with this issue and start working. :-) I just want to avoid reinventing the 
wheel.

Best regards,

Christian

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
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: local cache for offline-work

2010-07-09 Thread chen
On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote:
 On Friday 09 July 2010 at 18:01:53 chen wrote:
  [...]
  Let me try to summarize some pointers for calendar and you could do the
  same for address-book as well,
  + Create New ECalBackend for Kolab
  + Use the camel apis to fetch the calendar folder
  + Using the CamelFolder, get its contents. You would mime data and you
  can use the Camel libraries again to parse these contents.
  + Convert the Xml calendar data into Ics format and store it into the
  backend
 
 Yeah, this much is clear. There will be a fully-fledged two-way lossless 
 conversion between EDS data types and Kolab2 data types, and the conversion 
 will most probably be done on-the-fly (if we run into performance issues 
 here, 
 we might change plans... :).
 
  So this helps for displaying the contents. Now with creating
  meetings/appointments. iirc you would need to send them via smtp ?
  + use the camel_transport apis (look through e_cal_backend_save/send
  api's)
 
 Also no worries so far.
 
 Let me be a little more specific (I should have been right away, but my mails 
 tend to become lengthy...):
 
 * We need to create a local cache for emails which is handled by the plugin 
 backend(s).
 
 * Does there exist any infrastructure in E-D-S which will help us creating a 
 local email cache via IMAP?
Yes its available. CamelFolderSummary stores all the basic contents of
an email which needs to be displayed in the MessageList view (label,
subject, dates, fromto headers  etc.). CamelDataCache stores the
contents of the email (entire mime message) into the cache. The imapx
provider would use them to store the mail data into cache.

 
 * Orelse, is there a sensible way to re-use existing caching functionality 
 inside our backend which comes from Evolution, since Email handling resides 
 there, presently? Without weaving knots between Evo and E-D-S which will be 
 prone to failure and unclean, I mean?
Current imapx provider implementation is in such a way that, once you
access a message using camel_folder_get_message, the message would be
completely downloaded into the cache and would be available for offline
usage.

camel_folder_refresh_info would fetch the summary contents and
optionally fetch the message contents also if the folder is marked for
offline usage (when the camel url property, 'sync_offline' is set).

And i guess you would be re-using the existing imapx backend from
evolution ?

Once you convert the xml data to Ical or VCard, you can make them
available for offline usage based on ESource property, 'offline-sync'.
 
 
  There are many backend implementations already available file, exchange,
  groupwise etc. and you can refer them.. I would recommend looking
  through groupwise/exchange and shoot your questions if any..
 
 I'm in the process of having a closer look at them...
 
  Since no one has yet tried using camel apis, we do not know if there are
  any issues while you might face. But we should be able to help you while
  you progress..
 
 Okay, thanks.
 
 Once I'M really clear that we have to do these things fully on our own and we 
 cannot re-use existing infrastructure, I will instantly stop harassing you 
 with this issue and start working. :-) I just want to avoid reinventing the 
 wheel.
Oh np :) You can shoot your queries anytime.. Btw to be more clear no
one has tried using camel apis from calendar+address-book backends.

Thanks, Chenthill.
 
 Best 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


Re: [Evolution-hackers] evolution-kolab: local cache for offline-work

2010-07-09 Thread Christian Hilberg
Hi Chen,

thank you very much for taking time to clarify things! Much appreciated.

On Friday 09 July 2010 at 18:43:32 chen wrote:
 On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote:
  * Does there exist any infrastructure in E-D-S which will help us
  creating a local email cache via IMAP?
 Yes its available. CamelFolderSummary stores all the basic contents of
 an email which needs to be displayed in the MessageList view (label,
 subject, dates, fromto headers  etc.). CamelDataCache stores the
 contents of the email (entire mime message) into the cache. The imapx
 provider would use them to store the mail data into cache.

Okay, this helps. I think I saw these parts of Camel before, but I was not 
sure whether the facility provided would be sufficient for our needs. Seems we 
have what we need here.

  * Orelse, is there a sensible way to re-use existing caching
  functionality inside our backend which comes from Evolution, since Email
  handling resides there, presently? Without weaving knots between Evo and
  E-D-S which will be prone to failure and unclean, I mean?
 Current imapx provider implementation is in such a way that, once you
 access a message using camel_folder_get_message, the message would be
 completely downloaded into the cache and would be available for offline
 usage.
 camel_folder_refresh_info would fetch the summary contents and
 optionally fetch the message contents also if the folder is marked for
 offline usage (when the camel url property, 'sync_offline' is set).

Again, this is valuable information. If I read this correctly, the IMAPX 
implementation would handle all caching so we would be left with only the 
actual synchronization problem. BTW, is there a way to intercept Camel's 
synchronization with the IMAP server after reconnecting (i.e., after leaving 
offline mode)? This question is because the PIM emails hold semantics to which 
Camel will be agnostic (since it thinks it only handles emails), and it could 
be problematic to cope with PIM sync conflicts if Camel will just sync the 
emails right away without a possiblitiy for us to hook-in an awful lot of 
extra sync logic.

 And i guess you would be re-using the existing imapx backend from
 evolution ?

By all means! :-)

 Once you convert the xml data to Ical or VCard, you can make them
 available for offline usage based on ESource property, 'offline-sync'.

Well well, this all sounds promising.

 [...]
  Once I'M really clear that we have to do these things fully on our own
  and we cannot re-use existing infrastructure, I will instantly stop
  harassing you with this issue and start working. :-) I just want to
  avoid reinventing the wheel.
 Oh np :) You can shoot your queries anytime.. Btw to be more clear no
 one has tried using camel apis from calendar+address-book backends.

I think Matthew already mentioned this. But we will give it a try - not many 
options for us to choose from. :-) It might be a good idea to use separate 
instances of Camel providers for contacts and calendar data. We'll see.

Thanks for all the fish :-)

Christian


-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers