7:16 a.m.
Hello!
Since merging the Akonadi code, I focused on stabilizing and testing in
preparation for 1.1.99.4. I wanted to get a new update out this week;
unfortunately I am not yet ready to include Akonadi in the binaries or
the nightly testing.
Here are the details:
* I re-did the vCard extensions to avoid affecting non-Akonadi
syncs. Dinesh, please review the commit and re-test with
Akonadi. So far I only verified that the existing nightly
testing continues as it did before the merge.
* I fixed various other, minor build issues.
* I updated the reference build platform from Ubuntu Hardy 8.04 to
Ubuntu Lucid 10.04. Both are long-term support releases. The
advantage is that 10.04 contains a recent enough Akonadi; on
8.04 the code didn't compile cleanly. So theoretically,
syncevolution.org binaries can now be built including EDS and
Akonadi support.
Open issues:
* When KDE is active, crashes are caught by KApplication, which
leads to a GUI dialog about reporting the crash. This might be
useful, but where does it report the problem to? Can this be
disabled if it turns out to be not so useful?
* If both Akonadi and EDS are enabled and installed, which backend
does "backend = addressbook/calendar/todo/memo" choose? Both EDS
and Akonadi backends recognize such generic names. The original
goal was to let the person compiling SyncEvolution decide (by
only enabling the desired backend) or the user (by installing
only the right backend). The latter depends on packaging
backends separately, which is not currently done for
syncevolution.org binaries. There is only
"syncevolution-evolution".
Note that I had always intentionally added the -evolution suffix to
denote the package for EDS. I could try to create "syncevolution" core,
"syncevolution-evolution" and "syncevolution-kde". Not sure how easy
that is. Either way, I would prefer and additional solution:
* Introduce a SyncConfig::isPlatform(type) with type ==
GNOME/KDE/... plus possibly other values.
* EDS backends only react to generic names if platform == GNOME.
* Akonadi only if platform == KDE.
* The check itself can be based on the KDE env variable, at the
moment. If not set, assume GNOME.
* The KWallet check also needs to use isPlatform().
Later on we can make isPlatform() more sophisticated and even
configurable via a global config option.
Dinesh, can you prepare and test a patch for these issues?
About testing Akonadi sources, should this be based on Ovi or some of
the more mainstream servers, like Memotoo? In my testing with Ovi, I had
quite a lot of problems with network errors and timeouts.
Essentially we'll have to run EDS<->server and Akonadi<->server tests
independently of each other. That a server works well with EDS is no
guarantee that it'll work equally well with Akonadi: for simple tests
not involving specific data, it shouldn't matter, but in particular for
testItems it matters a lot. For that test, we also need KDE specific
test cases.
ical20.ics might be identical for KDE and EDS, but vcard30.vcf is
definitely EDS specific. Dinesh, can you provide a corresponding file
for KDE?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
9:36 p.m.
Hi Patrick
On Thu, Apr 21, 2011 at 4:46 PM, Patrick Ohly <patrick.ohly(a)intel.com>wrote:
* I updated the reference build platform from Ubuntu Hardy
8.04 to
> Ubuntu Lucid 10.04. Both are long-term support releases. The
> advantage is that 10.04 contains a recent enough Akonadi; on
> 8.04 the code didn't compile cleanly. So theoretically,
> syncevolution.org binaries can now be built including EDS and
> Akonadi support.
Great :)
Although the important thing for us is that we can only support KDE PIM
4.6(All Akonadi...) onwards and it is not yet out, so both 10.04 and 8.04
shouldn't make much of a difference for us. I hope we will have the KDE PIM
4.6 by Kubuntu 11.10.
Open issues:
> * When KDE is active, crashes are caught by KApplication, which
> leads to a GUI dialog about reporting the crash. This might be
> useful, but where does it report the problem to? Can this be
> disabled if it turns out to be not so useful?
Currently it will finally lead to KMail, where the user can manually mail
the Backtrace and other information (s)he wishes to provide to
syncevolution(a)syncevolution.org.
> * If both Akonadi and EDS are enabled and installed, which backend
> does "backend = addressbook/calendar/todo/memo" choose? Both EDS
> and Akonadi backends recognize such generic names. The original
> goal was to let the person compiling SyncEvolution decide (by
> only enabling the desired backend) or the user (by installing
> only the right backend). The latter depends on packaging
> backends separately, which is not currently done for
> syncevolution.org binaries. There is only
> "syncevolution-evolution".
> Note that I had always intentionally added the -evolution
suffix to
> denote the package for EDS. I could try to create "syncevolution" core,
> "syncevolution-evolution" and "syncevolution-kde". Not sure how
easy
> that is. Either way, I would prefer and additional solution:
> * Introduce a SyncConfig::isPlatform(type) with type ==
> GNOME/KDE/... plus possibly other values.
> * EDS backends only react to generic names if platform == GNOME.
> * Akonadi only if platform == KDE.
> * The check itself can be based on the KDE env variable, at the
> moment. If not set, assume GNOME.
> * The KWallet check also needs to use isPlatform().
> Later on we can make isPlatform() more sophisticated and
even
> configurable via a global config option.
> Dinesh, can you prepare and test a patch for these
issues?
Sounds good to me :) but currently I am in the midst of my University
exams.(they start tomorrow).... would be relieved after the first week of
May.. So will get to work immediately after that... so can this wait till
15th of the next month? (along with 2 code clean up patches in the queue for
the KJots specific sync) As of now, the code successfully builds and
everything works as it was before :)
> About testing Akonadi sources, should this be based on Ovi or some of
> the more mainstream servers, like Memotoo? In my testing with Ovi, I had
> quite a lot of problems with network errors and timeouts.
At this point of time I currently
only use Ovi, because of the Ovi sprint in
which we sent them a document for additional support. And I really haven't
heard from them after that. And I dunno what to expect, especially after the
Nokia Microsoft thing. So I think it is good that we test them against other
mainstream servers too.
Also you might be interested in the results of our first Akonadi <-- Akonadi Syncresults via. syncevolution http server.. I m
attaching the
file.. Almost everything is as expected, except for
1. ADR;TYPE=DOM;TYPE=HOME;TYPE=INTL;TYPE |
ADR;TYPE=HOME;TYPE=WORK:123;;Planet E,
2. The Birthday changing the format
3. The Photo showing differences, even though the other end didn't change
the photo..
4. The , being expanded to \, and \ being expanded to \\ with Ovi servers
isn't happening here...
------------------------- and
1. X-KADDRESSBOOK-OPENPGPFP:E51B7150FAF9 | ys
2. DFD3598EA760C7A89F438818028A
I currently guess that this is specific to the credentials on my PC
only....will have to confirm this...
This test is basically done with a VCard that I ve filled out manually in my
Kontact itself...
> ical20.ics might be identical for KDE and EDS, but
vcard30.vcf is
> definitely EDS specific. Dinesh, can you provide a corresponding file
> for KDE?
> --
> Best Regards, Patrick Ohly
> The content of this message is my personal opinion only
and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
Hello!
Since merging the Akonadi code, I focused on stabilizing and testing in
preparation for 1.1.99.4. I wanted to get a new update out this week;
unfortunately I am not yet ready to include Akonadi in the binaries or
the nightly testing.
Here are the details:
* I re-did the vCard extensions to avoid affecting non-Akonadi
syncs. Dinesh, please review the commit and re-test with
Akonadi. So far I only verified that the existing nightly
testing continues as it did before the merge.
* I fixed various other, minor build issues.
From what I ve asked around,
https://projects.kde.org/projects/kde/kdepimlibs/repository/revisions/mas...
These are the files that have been used for testing...
Cheers,
Dinesh
Essentially we'll have to run EDS<->server and Akonadi<->server tests
> independently of each other. That a server works well with EDS is no
> guarantee that it'll work equally well with Akonadi: for simple tests
> not involving specific data, it shouldn't matter, but in particular for
> testItems it matters a lot. For that test, we also need KDE specific
> test cases.
7:54 a.m.
On Mo, 2011-04-25 at 02:36 +0100, Dinesh wrote:
Hi Patrick
On Thu, Apr 21, 2011 at 4:46 PM, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
Hello!
Since merging the Akonadi code, I focused on stabilizing and
testing in
preparation for 1.1.99.4. I wanted to get a new update out
this week;
unfortunately I am not yet ready to include Akonadi in the
binaries or
the nightly testing.
Here are the details:
* I re-did the vCard extensions to avoid affecting
non-Akonadi
syncs. Dinesh, please review the commit and re-test
with
Akonadi. So far I only verified that the existing
nightly
testing continues as it did before the merge.
* I fixed various other, minor build issues.
* I updated the reference build platform from Ubuntu
Hardy 8.04 to
Ubuntu Lucid 10.04. Both are long-term support
releases. The
advantage is that 10.04 contains a recent enough
Akonadi; on
8.04 the code didn't compile cleanly. So theoretically,
syncevolution.org binaries can now be built including
EDS and
Akonadi support.
Great :)
Although the important thing for us is that we can only support KDE
PIM 4.6(All Akonadi...) onwards and it is not yet out, so both 10.04
and 8.04 shouldn't make much of a difference for us. I hope we will
have the KDE PIM 4.6 by Kubuntu 11.10.
So in platforms like Ubuntu Lucid and Debian Squeeze (current stable),
what is Akonadi really used for? It's certainly in the platform. Are you
saying that KDE doesn't fully use it yet? Then how useful is
synchronizing data stored in it before KDE PIM 4.6?
I am not keen on having to provide pre-compiled binaries for lots of
platforms. If I can make it work by compiling on Ubuntu Lucid, my life
would be a lot easier.
Open issues:
* When KDE is active, crashes are caught by KApplication,
which
leads to a GUI dialog about reporting the crash. This
might be
useful, but where does it report the problem to? Can
this be
disabled if it turns out to be not so useful?
Currently it will finally lead to KMail, where the user can manually
mail the Backtrace and other information (s)he wishes to provide to
syncevolution(a)syncevolution.org.
That should be fine.
* If both Akonadi and EDS are enabled and installed,
which backend
does "backend = addressbook/calendar/todo/memo" choose? Both
EDS
and Akonadi backends recognize such generic names. The original
goal was to let the person compiling SyncEvolution decide (by
only enabling the desired backend) or the user (by installing
only the right backend). The latter depends on packaging
backends separately, which is not currently done for
syncevolution.org binaries. There is only
"syncevolution-evolution".
Note that I had always intentionally added the -evolution suffix to
denote the package for EDS. I could try to create "syncevolution"
core,
"syncevolution-evolution" and "syncevolution-kde". Not sure
how easy
that is. Either way, I would prefer and additional solution:
* Introduce a SyncConfig::isPlatform(type) with type ==
GNOME/KDE/... plus possibly other values.
* EDS backends only react to generic names if platform == GNOME.
* Akonadi only if platform == KDE.
* The check itself can be based on the KDE env variable, at the
moment. If not set, assume GNOME.
* The KWallet check also needs to use isPlatform().
Later on we can make isPlatform() more sophisticated and even
configurable via a global config option.
Dinesh, can you prepare and test a patch for these issues?
Sounds good to me :) but currently I am in the midst of my University
exams.(they start tomorrow).... would be relieved after the first
week of May.. So will get to work immediately after that... so can
this wait till 15th of the next month? (along with 2 code clean up
patches in the queue for the KJots specific sync) As of now, the code
successfully builds and everything works as it was before :)
15th next month may be too late for a SyncEvolution 1.2 release. But we
could do a 1.2.1 update shortly afterwards which then would include
Akonadi support.
About testing Akonadi sources, should this be based on Ovi or
some of
the more mainstream servers, like Memotoo? In my testing with Ovi, I had
quite a lot of problems with network errors and timeouts.
At this point of time I currently only use Ovi, because of the Ovi
sprint in which we sent them a document for additional support. And I
really haven't heard from them after that. And I dunno what to expect,
especially after the Nokia Microsoft thing. So I think it is good that
we test them against other mainstream servers too.
Okay, so let's do that first.
Also you might be interested in the results of our first Akonadi
<-->
Akonadi Syncresults via. syncevolution http server.. I m attaching the
file.. Almost everything is as expected, except for
ADR;TYPE=DOM;TYPE=HOME;TYPE=INTL;TYPE | ADR;TYPE=HOME;TYPE=WORK:123;;Planet E,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not supported like this in the internal Synthesis representation. From
the vCard profile:
<parameter name="TYPE" default="yes"
positional="no" show="yes">
<value field="ADR_STREET_FLAGS" conversion="multimix"
combine=",">
<enum name="HOME" value="B0"/>
<enum name="WORK" value="B1"/>
<enum mode="ignore" value="B2"/> <!-- OTHER
-->
<!-- enum mode="prefix" name="X-CustomLabel-"
value="1.L"/ -->
<!-- enum mode="prefix" name="X-Synthesis-Ref"
value="2.L"/ -->
</value>
</parameter>
We would have to add other types.
BTW, does combining TYPE=DOM and TYPE=INTL really make sense? From the
RFC:
The TYPE parameter values can include "dom" to indicate a
domestic delivery address; "intl" to indicate an international
delivery address
That sounds mutually exclusive to me.
The Birthday changing the format
From 2010-12-31 to 20101231 or vice versa? Both is allowed. As long as
KDE swallows the format produced by the Synthesis encoder, we don't need
to worry.
The Photo showing differences, even though the other end
didn't change the photo..
Reencoding somewhere? A log at loglevel=4 would show us more - typically
that is needed when tracking down data conversion issues.
The , being expanded to \, and \ being expanded to \\ with
Ovi servers isn't happening here...
------------------------- and
X-KADDRESSBOOK-OPENPGPFP:E51B7150FAF9 | ys
DFD3598EA760C7A89F438818028A
Same here: hard to tell without full log.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
3595
days inactive
3600
days old
syncevolution@synevolution.org
2 comments
2 participants
participants (2)
-
Dinesh -
Patrick Ohly