[SyncEvolution] Google Calendar sync
by Patrick Ohly
Hello!
As those who have tried the "google" config template know, only contact
synchronization over SyncML works, because that is all that Google
supports. Those who want to synchronize their Google calendar have to
use third-party bridges to that data (ScheduleWorld, Goosync).
http://bugzilla.meego.com/show_bug.cgi?id=319
A "native" solution would be to access the Google calendar via CalDAV. I
gave that a try, using the Evolution Data Server CalDAV/Google backend
as implementation of the protocol. In theory, this should have worked
out-of-the-box with SyncEvolution, although setting it up would be
fairly complex:
* set up syncevo-http-server to access Google calendar
* set up a client config to access the normal local calendar and
syncevo-http-server
* run command line with "--daemon=no", because that is currently
the only way how we can have SyncML client and server on the
same host
In practice I ran into several problems which makes this approach
unusable right now. For those who are interested in details, below is a
description of the problems.
My conclusion right now is:
1. We need a better solution for backend A<->backend B syncs (I
sometimes call that "local sync").
2. We should better write a CalDAV backend instead of relying on
EDS. Not only will that avoid the issues below (which could be
fixed), such a backend would also be useful for users not
interested in running EDS and perform better. I'm assuming here
that CalDAV has functionality that would helps us (like
efficient listing of all items) which we can't use when going
through EDS because it doesn't have corresponding APIs.
Any CalDAV experts or volunteers around? The second task could be
started already with the current code base. If no-one volunteers, then
it'll end up on the backlog of feature requests.
-------------------------------------------
Here's how I set up testing:
* create two test calendars in Google
* create the same calendars in Evolution, using Google_ical20_1
and Google_ical20_2 as names (naming expected by client-test,
setting the evolutionsource property to the right caldav:// URL
should work without creating the calendars in Evolution)
* run CLIENT_TEST_EVOLUTION_PASSWORD=<password>
CLIENT_TEST_EVOLUTION_PREFIX=Google_ ./client-test
Client::Source::ical20
First problem: our test data uses a UID with special characters, because
that happens to break "dumb" XML encoders/decoders and we want to find
such issues. It also breaks the EDS backend. It can create such an
event, but then cannot access it because the UID becomes of a URL used
by WebDAV, and these special characters are not escaped there (seen in
evolution-data-server console output).
As a workaround, I simplified the test data to not use such a
complicated UID when CLIENT_TEST_SIMPLE_UID=1 is set.
Still no luck. client-test can create an item, but then retrieving it
fails. The root cause for that is the backend's implementation of
e_cal_create_object(). It should return the ID assigned to the new
object, but for the WebDAV EDS backend it returns an empty string
instead of the correct ID. Iterating over all objects later shows that
the ID is something like http://www.google.com/calendar/feeds/<unique ID
of calendar>%
40group.calendar.google.com/private/full/jjs14jjurojsoi7koo3op1vq3g
Even if e_cal_create_object() worked, we wouldn't trust it in
SyncEvolution, because it was broken in the past. From the code:
// creating new objects works for normal events and detached occurrences alike
if(e_cal_create_object(m_calendar, subcomp, (char **)&uid, &gerror)) {
// Evolution workaround: don't rely on uid being set if we already had
// one. In Evolution 2.12.1 it was set to garbage. The recurrence ID
// shouldn't have changed either.
ItemID newid(!id.m_uid.empty() ? id.m_uid : uid, id.m_rid);
newluid = newid.getLUID();
modTime = getItemModTime(newid);
m_allLUIDs.insert(newluid);
}
In other words, when a VEVENT has a UID, we use that as local ID. That's
the best we can do, because the "garbage" really is a random pointer as
far as I remember, so we cannot use it at all.
--
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.
11 years, 11 months
[SyncEvolution] How to select the evolution target calendar
by Matthias Urlichs
Hello,
I have one small problem: I cannot select which local Evolution calendar
SyncEvolution actually talks to.
Apparently it uses the first entry in
the /apps/evolution/calendar/sources gconf entry that it can find. Since
the order of these entries isn't changeable and I need to separate
"work" from "home" calendar entries (with separate mobiles to sync to
…), I'd like some way to change that.
Either this is not possible yet, or I'm blind and didn't find it in the
documentation …?
Otherwise, thanks for the excellent tool; it works with our Oracle
calendar like a charm (using the values in the Oracle branch).
-- Matthias
12 years
[SyncEvolution] single source for documentation (MBC #690)
by Patrick Ohly
Hello!
Everyone, I'm updating the documentation. Feedback please - I'm not
doing this for myself ;-)
Mike, I have a question about Drupal - see last paragraph.
Quoting http://bugs.meego.com/show_bug.cgi?id=690:
Keeping separate chunks of documentation in sync is an ongoing effort. Perhaps
we can simplify that task by keeping a single set of source files and generate
all other documentation from it automatically.
The documentation that would be nice to have is:
* README: plain text, the file that is currently maintained in git
* man pages for syncevolution, synccompare, sync-ui: doesn't exist at the moment
* the "Usage" page on syncevolution.org for the command line
As a first step (BMO#4633) the docs which have already diverged need to be
merged again. Then we need a single source format and corresponding make rules
which will generate the rest.
Today I look into this issue a bit more seriously. Originally, I
suggested Perl POD as that shared format, primarily because it is old
and typically installed on build systems.
But I never really liked the format. reStructuredText seems so much
nicer, so I did some more experiments with it and rst2man (in
python-docutils >= 0.6 (?)).
I was pleasantly surprised how easy it was to copy text from the README
into a README.rst. Very little changes were necessary to the markup. For
the most part, README.rst can still be read like a normal text, one of
the big strengths of rST. Question: should I strip the suffix when
preparing a release (install as README), replace with .txt (install as
README.txt) or leave it as it is?
The advantage of .rst is that Emacs and other tools (GNOME) recognize
the format. The disadvantage is that it might not always be recognized,
thus forcing to select a plain text reader.
The only part where markup is non-intuitive are some extra :: colons to
get the following text marked as a literal block and quoting a hyphen
where it was mistaken for something else:
\--migrate
In older SyncEvolution releases a different layout of configuration files
was used. ...
I find good enough to simply replace README with README.rst, without
doing any modifications to it.
The other change that I made is to reorganize the content so that it is
more like a reference man page. First, this minimizes the overlap with
instructions found elsewhere on syncevolution.org. Second, it was an
incentive to document some aspects (environment variables!) which were
not documented before.
Attached is a copy. What do you think about these changes? Any spelling
mistakes, unclear statements, etc.?
The conversion to man format works fine. Because rst2man is not always
installed, the man page would be optional. I'm attaching the man page
(syncevolution.1) and a rendered output (without escape codes, use "man
-l syncevolution.1" in a terminal if you want bold and underlined text).
Conversion to HTML also works and the result can be copied almost
verbatim into Drupal with "Full HTML" as format:
http://syncevolution.org/wiki/main-page
The goal is to replace the "Usage" page
(http://syncevolution.org/documentation/syncevolution-usage) with this
rendered man page.
"Copied almost verbatim" because that format differs from HTML in one
aspect: line breaks inside a paragraph are turned into a <br/>. I find
that inconvenient, because it also forces me to remove line breaks from
my announcement emails when I copy/paste them into Drupal. To me, it
also seems to deviate from normal Markdown syntax which normally uses
extra whitespace at the end of a line to insert <br/>
(http://daringfireball.net/projects/markdown/syntax#p).
Mike, is this a Drupal-specific extension? Can it be turned off?
--
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.
12 years
[SyncEvolution] Genesis' future
by Frederik Elwert
Hello everybody,
I’m crossposting this on SyncEvolution and Genesis mailing lists, as it
might be interesting for all.
I am currently thinking about the future direction of Genesis
development. Genesis started with very limited aims: I didn’t want to
open a terminal window in order to execute syncevolution, so Genesis
provided a notification area icon which could start syncs and informed
about the results using libnotify.
Since syncevolution didn’t have a GUI, a simple setup assistant was
added to make it easier to get started with SyncEvolution. And Genesis
allowed for automated syncs.
The situation has changed, though. SyncEvolution now ships its own GUI,
sync-ui. Automated syncs are in the syncevolution core. And
SyncEvolution grows quite fast feature-wise, e.g. Bluetooth sync,
HTTP-Server support, etc. This leads to a situation where I want to
think about the future of Genesis. I can think of two possible
directions:
1. Make Genesis a full SyncEvolution GUI, which can serve as a
replacement for sync-ui. Since sync-ui is tailored towards
Netbooks and looks a bit awkward in a standard GNOME
environment, having a more desktop-like alternative might be
appreciated. David’s current work on an Account Manager for
Genesis leads in this direction, but quite a lot of effort would
be needed in order to make Genesis nearly as complete as
sync-ui. (Most visible: Bluetooh support, mostly invisible, but
important: Error handling.)
2. Go back to the roots and leave everything else to sync-ui.
Genesis could limit itself to providing a status icon for quick
access and provide notifications. It should then integrate
tighter with sync-ui (e.g., show notifications also for sync-ui
triggered syncs, open sync-ui for configuration tasks, etc.).
First work is done by switching to D-Bus for SE session
handling.
I currently tend towards the second option. My time for working on
Genesis is limited, and so it makes sense not to duplicate the work that
already was made for sync-ui. But it would also be possible to split
Genesis’ current features into two separate components: A small status
+notification app and a stand-alone application with account management
and all.
Before I definitely decide on this, I would like to hear your opinion:
As developers, but even more as users. What would be your favorite
Genesis?
And if anyone wants to work on Genesis, in one direction or the other,
help is always appreciated.
Cheers,
Frederik
12 years
[SyncEvolution] Contacts - two possible bugs? - IM field, adr field
by Jeff
[I'm doing all testing in a virtual machine including an n900 emulator]
In the course of my testing, I decided to create a jumbo contact and
fill all it's fields (in evolution), then sync to the N900.
Exporting and comparing the contact on each side, then running
synccompare reveals the following changes.
1) IM contact fields used in test: AIM, Jabber, Yahoo, SKYPE
Observed: N900 side after sync shows that the
portion of the VCF for the IM field that says "TYPE=HOME"
has been removed from Skype and Jabber but NOT AIM or Yahoo
N900 does NOT display these contact fields
Expected: No change in VCF
N900 SHOULD display skype and jabber contact detail
2) Address field (ADR in the VCF) for Home address, work address and
Other addresses appear to have had an extra space inserted after the
semicolon for the zip field (in th VCF) causing an extra space
in the country field at it's start
Seems to me the 1st issue could cause problems syncing back to N900 IF
Evolution cared about TYPE for IM fields. Right now it does not seem to
care.
Both seem like issues... please let me know your thoughts on these...
--Jeff
12 years
[SyncEvolution] N900 PR1.2 Release and obtaining Syncevolution 0.9.2
by Jeff
I have been doing some testing in scratchbox - the March release of that
environment was a preview of PR1.2 so I've been testing with the
latest.
The official PR1.2 release reached my physical N900 yesterday :)
I am now considering installing syncevolution on it.
FYI Here is what I've found so far
Before PR1.2 - IN THE EMULATOR (March release)
I enabled extras and extras-testing and was able to fetch syncevolution
0.9.2 and install it and syncevolution-frontend.
Before PR1.2 - on the physical N900
Same repositories only seemed to make version 0.6 of syncevolution
available... this is puzzling.
Any ideas?
I was also unable to install 0.9.4 - I tried to do so by visiting the
maemo package page for syncevolution and downloaded and attempted to
install the debian package- apparently it needs a newer version of
libpcre and possibly other packages. I concluded that perhaps it now
needed PR1.2 and some of it's newer libraries...
After PR1.2 - on the physical N900
The new Extras repository distribution is known as fremantle-1.2
and will house apps linked against the newer gui libs
fremantle-1.2 does not contain syncevolution
Question: Has anyone tested syncevolution and syncevolution-frontend
packages from the fremantle exras testing repository to see if they work
under PR1.2?
I suspect the answer is yes, and that they work fine (since they have
been inside the scratchbox N900 emulator)....
I may just go ahead and try it tomorrow sometime...
(US time)
Question: Any plans to make syncevolution available in fremantle-1.2
It would be nice if it could continue to be made visible for upgraders.
--Jeff
12 years
[SyncEvolution] D-Bus questions
by Frederik Elwert
Hello everybody,
while I am currently in the process of rewriting Genesis along the lines
of my previous e-mail, some questions about how to properly integrate
with the D-Bus server and other clients came up. I guess it now shows
that I’m not a computer scientist, so I need some assistance from
somebody with more profound knowledge.
1. Getting sync reports from third party sessions.
One of my attempts for the re-write is to better integrate
Genesis with other clients, like sync-ui. So I want to show that
a sync is in progress (animated icon) and a result report
(notification bubble) for syncs triggered by other clients.
I can easily listen to the `StatusChanged` signal of a newly
created session and show that a sync is in progress by waiting
for the 'done' status. But when I want to get the result of that
sync by calling `session.GetReports(0, 1)`, it fails with a
D-Bus error. I guess that this is because sync-ui already called
`session.Detach()`.
So what would be the best way to get a sync report from a
session that I did not create by myself? Is there a way to
"attach" to a third-party session in order to prevent it from
being destroyed?
2. Getting information about the purpose of a session
When I want to sync, I create a session. Because I have to wait
for the session to become ready, I connect to the
`SessionChanged` signal. But of course, I get a `SessionChanged`
for all sessions, not just the one I just requested for syncing.
So how do I know that the session I am getting notified about is
the one I requested for the sync?
Currently, I am storing the purpose of a session, along the
lines of
session_path = syncevo_server.StartSession(server)
sessions[session_path] = 'sync'
Then, when I get the `SessionChanged` signal, I can ask for the
purpose:
if sessions[session_path] == 'sync':
session.Sync('', {})
But there is a race condition between storing the sync info and
getting the `SessionChanged` signal. So I used a sleep:
while not session_path in sessions:
time.sleep(0.1)
But this is a) ugly, and b) only works assuming all sessions are
created by myself, because a session created by a third-party
client will never show up in `sessions`.
So to make a long story short: How would I properly know if a
session I get the `SessionChanged` signal for is requested by me
in order to perform a sync?
(I tried to understand what sync-ui does, but miserably failed
reading the source code. That is way too deep for me.)
Thanks in advance,
kind regards,
Frederik
12 years
[SyncEvolution] migration of git repository
by Patrick Ohly
Hello!
The intention is to move the git repositories for SyncEvolution and our
branch of libsynthesis from git.moblin.org to meego.gitorious.org. git
can mirror repositories, so moving the data is easy. I already copied a
current snapshot:
http://meego.gitorious.org/meego-middleware/syncevolution
http://meego.gitorious.org/meego-middleware/libsynthesis
Right now, the repos on moblin.org are still the ones where changes are
made first.
We need to coordinate the switch a bit:
* I need to change translate.moblin.org so that it pushes into the
new repos.
* Developers need to change the URL in their .git/config file:
replace "git.moblin.org:" with
"gitorious.org:meego-middleware/".
The old repos will stay around, which may become confusing when people
go there and only find old code. Should we set up a mirror script or
request that the repos be removed?
I'd like switch fairly soon, perhaps even today. The reason for the
haste is that our nightly build server has issues checking out the
sources from moblin.org. gitorious.org seems to work better.
--
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.
12 years
[SyncEvolution] Address Book Sync Problem
by Gordon Dickens
Hello,
I have been using syncevolution with my own funambol server for well
over a year without any problems. I had syncevolution running on a
Ubuntu Hardy 8.04 laptop where everything worked great until just
recently when I upgraded to Ubuntu Lucid 10.04. Now, syncevolution
doesn't sync the address book properly and I am at my wits end to figure
out what the problem is and how to fix it. So far, I have identified
the following three problems:
1) When I add a contact to the address book, syncevolution transmits the
contact to my funambol server, however, it omits including the email
address which is left blank on the funambol server after the sync operation.
2) When I delete a contact in the address book, syncevolution does not
delete the corresponding contact on the funambol database.
3) syncevolution always reports "No Changes Necessary" even when the
database has changed.
I have tried two versions of syncevolution as follows:
1) The version that comes with the Ubuntu Lucid repo (which is listed as
1.0+ds1~beta2a-1).
2) The "stable" version from the syncevolution.org site's repo (which is
named syncevoution-evolution and is listed as version 1:0.9.2-2).
I am running evolution version 2.28.3 on my Ubuntu Lucid laptop and
Funambol Server version 8.5.1 on a remote CentOS 5.4 server.
I hope that somebody can provide me some guidance for fixing this. I've
been beating my head against the wall for well over a day without
success. Is there another version of syncevolution that I should try
with evolution version 2.28.3 and funambol server 8.5.1?
Many Thanks!
Gordon Dickens
12 years
