[SyncEvolution] bridgie syncml server and caldav/card dav server
by Robert Schetterer
Hi, is there a chance to use syncevolution
as a bridge between a syncml server and a caldav/carddav server and vice
versa
i.e horde or funambol server syncml and DAViCal etc
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
10 years, 3 months
[SyncEvolution] problems with self-signed certificate with syncevolution on Nokia n900
by karlitos＠seznam.cz
Hello
I can not sync my Nokia N900 with horde groupware edition, which runs on my server, as long as I try to establish connection over https. Connection without SSL or using the SSLVerifyServer=0 option does the job, so I guess the problem can not lies elswhere by some wrong settings.
The certificate is self-signed and there are no problems with other programs like web browser. I imported the certificate manualy and I can confirm the certificate is placed under /home/user/.maemosec-certs/ssl-ca. I also compared the imported certificate with the original one from my server and there are no differences. So I put "SSLServerCertificates = /home/user/.maemosec-certs/ssl-ca" in the settings. But every sync-attemp ends with a "transport failed,retry period exceeded" error.
I found this message http://www.mail-archive.com/syncevolution@syncevolution.org/msg01952.html so probably I am doing something wrong. But I am not able to figure out what.
If I do not use the SSL connection but set the MD5 athentication method - will this be as safe, as the SSL connection ?
Any help would be appreciated, thanks in advance Karel
11 years
[SyncEvolution] need help getting n900 working with davical
by Jelle de Jong
Hello everybody,
So after many months I was excited to try syncevolution with caldav and
carddav support today.
I executed my configuration commands as earlier posted on this mailing-list.
Please see the bellow pastebin URL that contains the details (versions,
configuration, and syncevolution commands)
http://paste.debian.net/124460/
The only n900 how-to I could find was:
http://talk.maemo.org/showthread.php?t=40278
Could somebody have a look at the pastebin and can tell me what I am
doing wrong? and what I should do to make the N900 calender and contacts
use caldav and carddav by default!
Thanks in advance,
Kind regards,
Jelle de Jong
11 years
[SyncEvolution] adding new adress-book entries/field-definitions on the server side
by karlitos＠seznam.cz
Hello
I was able to set up sync between my horde 4 groupware edition and my nokia n900 using syncevolution. I had to make a small improvement to the horde groupware by adding the entries homeEmail and workEmailto the frontend and the DB backend and now I can sync the normal, home- or work-email between the phone and the groupware.
I just followed thios howto : http://edeca.net/wp/2010/01/modifying-fields-in-the-turba-addressbook/
I would like to add more fileds, like gender or skype account - which are pressent in the n900 adress book. Can somebody please explain to me where can i find the definitions about how to define this fileds, so the syncevolution recognize them right ?
For example here is the definition of homeEmail :
$attributes['homeEmail'] = array(
'label' => _("Home Email"),
'type' => 'email',
'required' => false,
'params' => array('allow_multi' => false, 'strip_domain' => false, 'link_compose' => true)
);
For example I am totaly unsure about the "type" of the field gender i would like to set.
Thanks in advance for an explanation Karel
11 years
[SyncEvolution] vcalendar-sqlite
by Roger KeIrad
Hi,
To develop calendar sqlite backend that synchronize vcalendar what should i
use ?
cause i didn't understand very well the syncevolution architecture :
interaction between different libraries.. i only want to use the
syncevolution client part.
what libraries did i need ?
THX
11 years
[SyncEvolution] ebook /ecal
by Roger KeIrad
Hello
I want just to use the syncevolution client part .
Did i need the ecal and ebook library to synchronize events and addressbook
?
THX
11 years
[SyncEvolution] SyncEvolution 1.1.99.5 released: now also with CalDAV/CardDAV
by Patrick Ohly
SyncEvolution 1.1.99.5 "beyond SyncML"
======================================
Release 1.1.99.5 is the first release candidate for 1.2. It has gone
through a long stabilization period and thus is suitable for normal users.
For those not familiar with the project, SyncEvolution synchronizes
personal information management (PIM) data like contacts, calenders,
tasks, and memos using the SyncML or the CalDAV/CardDAV protocols.
Up to and including 0.9.2, a third-party SyncML server was required.
Since 1.0, SyncEvolution itself is able to act as a SyncML server,
both via HTTP and Bluetooth (direct sync with phones).
Changes 1.1.1 -> 1.1.99.5
=========================
The major new feature of the 1.2 release is support for non-SyncML
protocols in general and CalDAV/CardDAV in particular. ActiveSync
support is in development. These protocols are implemented as backends
which are combined with other backends by SyncEvolution in a so called
"local sync". The GTK sync-ui does not yet support configuring
non-SyncML protocols. See the README and man page for more information
on how to use the new feature via the command line:
http://syncevolution.org/documentation/syncevolution-usage
Properties not supported by SyncML servers can now be preserved
locally in two-way synchronization (BMC #15030). This depends on
information about what properties a SyncML server supports ("CtCap"),
which is typically not provided by servers. SyncEvolution contains a
copy of that information for Google Contacts (BMC #15029).
Akonadi backend and KWallet support were merged. They are not included
yet in syncevolution.org binaries. To use them compile from source.
The configuration format was updated to solve a conceptual problem
inherited with the legacy property names: the "type" property had
multiple, sometimes conflicting roles. For example, setting the
preferred data format for sync with one peer might have changed the
backend selection for some other peer (BMC #1023). Now
"backend/databaseFormat/syncFormat/forceSyncFormat" replace
"type". "type" is still accepted by the command line as alias.
Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. In contrast to
earlier, more experimental releases in the 1.2 series, 1.1.99.5 and
later automatically migrate configurations. The old configurations
will still be available (see "syncevolution --print-configs") but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.
Other changes:
* a problem with enabling release mode required replacing 1.1.99.5
with a fixed 1.1.99.5a release
* syncevo-http-server was enhanced considerably. See http://syncevolution.org/wiki/http-server-howto
* support NetworkManager API >= 0.9 (BMC #19470)
* Sync mode is recorded when running in SyncML server mode (BMC #2786).
* syncevo-dbus-server automatically stops when some of its libraries
are updated and restarts if auto-syncing is on (BMC #14955).
* Using the --sync-property and --source-property command line options is
optional, just specifying the property assignment is enough.
* Added support for Buteo, mKCal and QtContacts in MeeGo.
Buteo and mKCal were removed again from MeeGo, so the code
is obsolete. The QtContacts backend may be still be useful
to access items via that API, but for syncing on MeeGo
the normal EDS backend is used since MeeGo reverted back
to EDS as PIM storage.
* code cleanup and various minor fixes/improvements, see ChangeLog
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2011/syncevolution-11995-beyond-sync...
Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources
i386, amd64 and lpia binaries for Debian-based distributions are
available via the "unstable" syncevolution.org repository. Add the
following entry to your /apt/source.list, then install
"syncevolution-evolution":
deb http://downloads.syncevolution.org/apt unstable main
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can
no longer be supported with precompiled binaries because of missing
libraries, but the source still compiles when not enabling the GUI (the
default).
The same binaries are also available as .tar.gz and .rpm archives in
http://downloads.syncevolution.org/syncevolution/evolution. In contrast
to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the
content must be moved to /usr, because several files would not be found
otherwise.
After installation, follow the
http://syncevolution.org/documentation/getting-started steps.
--
Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution possible:
http://syncevolution.org/about/contributors
11 years
Re: [SyncEvolution] Bug #11251 - notes synchronization
by Patrick Ohly
On Fr, 2011-07-08 at 15:13 +0100, Valluri, Amarnath wrote:
> I was looking this bug/feature :
> https://bugs.meego.com/show_bug.cgi?id=11251, assigned to me.
>
>
>
> I spent almost two/three days to go through all the code related to
> this, and XML configuration of data types etc. But couldn’t get enough
> to start implementing the changes.
No surprise, this issue touches on all of the Synthesis internals.
Learning about those takes a while ;-)
> My Understanding is :
>
> Currently ‘Note’ datatype is configured as ‘plain/text’ in synthesis
> xml configuration with two fields, SUBJECT and TEXT. Hence it can’t
> store additional fields like CATEGORIES of imported items.
>
> So we need to expand this datatype to accommodate whole Memo
> information.
Yes. But don't invent your own field list. Just use the existing
"calendar" fieldlist. Then add a VJOURNAL sub-profile to the "vCalendar"
mimeprofile. That'll enable synchronizing memos/notes as iCalendar 2.0,
between peers which support that.
Then change the "Note" textprofile so that it uses the "calendar"
fieldlist. That should take care of conversion to/from plain text.
> And even the text<->VJOURNAL conversion is happening in
> backend(EvolutionMemoSource) which should be avoided.
This conversion needs to be removed. EvolutionMemoSource itself probably
becomes obsolete.
> My Doubts are :
>
>
>
> i) you said in bug description that “configure
> plaintext datatype which uses same field list as calendar”, But this
> datatype is already existing, should we add fields to this?
>
> OR Can’t we have a sub-profile in Calendar profile as VJOURNAL ?, I
> mean can we save memo’s also as calendar events L.
The latter.
> ii) I gone through SynthesisDBPlugin, SythesisEngine
> and SyncSource code. But I couldn’t get exactly where and how these
> configured datatypes/fields are being used in the engine side,
>
> while reading and writing the items.
Have a look at SyncSourceBase::getDatastoreXML() in SyncSource.cpp. This
is where the Synthesis XML config is being generated for each source.
You'll find that it selects datatypes there.
> iii) I am not clear How this type conversion to move
> to Engine. and Say if we configure this type in engine, I hope we can
> drop whole MemoSouce(.cpp) code. Am I right ?
Right.
--
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
[SyncEvolution] Website: Simple structure changes
by Murray Cumming
I suggest some simple structural changes to the website, to make things
clearer:
1. Remove the wiki link.
We should just accept that the website _is_ a wiki. That "main page"
page has become a target of random user feedback. That's not the best
place for it.
Partly because of the text sizes and layout, the comments look like main
(rather random) content at first glance.
The "Wiki Pages" list block can be moved to the Documentation page. By
the way, how do we add to that list?
2. Remove About
- The first paragraph duplicates the introductory text on the Home page.
- Move part of History to the Home page, simplifying it.
- Move Features to the Home page.
- Move "SyncEvolution Core and Synthesis SyncML Engine", "Backends", and
"Frontends" to Documentation as separate sub-pages, linking to them from
our introductory text on the Home page.
3. Add a real Downloads page.
This is currently just a directory listing. There should be some brief
text and a description of each binary and how to install it.
2. Remove comments.
The comments don't seem like the best way to deal with feedback, and
they distract from the main contact. Even in the best case, old comments
will still be there after their feedback has been dealt with by
improvements in the page itself, distracting from that content and
giving the initial impression that those problems still exist.
--
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
11 years
Re: [SyncEvolution] dbus-server-reorganization progress
by Patrick Ohly
On Mi, 2011-07-27 at 10:30 +0200, Chris Kühl wrote:
> On Wed, Jul 27, 2011 at 9:07 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > On Mi, 2011-07-27 at 01:45 +0200, Chris Kühl wrote:
> >> I've tried my dbus-server-reorg branch with this change as well as
> >> your dbus-server-reorg-pohly-libsynccommon branch but I still get the
> >> same results as before.
> >
> > Just to be sure, you mean the "no backends available in static
> > compilation" problem?
> >
> > The last commit fixed it for me. Anyway, the little benefit of compiling
> > the source files less often is not worth the hassle. I'll revert to
> > including the core source files in all executables.
> >
>
> This is the error I get for the TestConnection.testCredentialsRight for example,
> DBusException: org.syncevolution.InvalidCall: invalid value 'file' for
> property 'backend': 'not one of the valid values (virtual, calendar =
> events, addressbook = contacts, todo = tasks, memo = memos = notes)'
I forgot that we were talking about the syncevo-dbus-server. My patch
was only for the syncevolution binary. Because of its ugliness I must
have shied away from applying the same trick/hack to all binaries -
sorry for that.
I went ahead with reverting this ill-fated liaison with a libtool
convenience library - not so convenient after all... Exercise for the
reader: decide whether I meant libtool or its convenience libs.
As part of rebasing the dbus-server-reorganization-pohly branch I did a
few more things:
* include the AutoSyncManager syncDone fix (BMC #21888)
* fixed a compile error in the WebDAV backend due to the "Clean up
namespace pollution" patch
* moved D-Bus server sources into src/dbus/server and squashed
with the cleanup fixes for the original renaming to src/server
* removed accidental commit and its revert
Regarding the directory renaming we've had a misunderstanding. When I
said that the "dbus" should hold everything SyncEvolution D-Bus related,
that was meant to include the server.
The Notification* classes should also be moved there - not done yet, in
case that they need further work.
I'll probably have a look at compile times once all of this is in master
(= directly after 1.2 release). Pushing a lot of files into
sub-directories limits parallelism in "make -j", which is particularly
obvious on our shiny new nightly build machine (8 real cores). I also
saw on my laptop that compiling these *Register.cpp files multiple times
does consume noticeable time - perhaps there is a better solution after
all.
Tests are currently running. TestConnection.testCredentialsRight passed
already, so I am pushing my dbus-server-reorganization-pohly branch.
--
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
