1:17 p.m.
Hello all!
I have implemented an ActiveSync backend for the ActiveSync
implementation developed by Mobica. Code is currently in the activesyncd
git repo. It is hosted there because the activesyncd library API is not
stable yet. Long term it'll probably move back to SyncEvolution.
I only tried compilation inside SyncEvolution. I haven't even tried to
run it at this point. I'll try to find the time for that tomorrow.
See the README for more instructions:
http://git.infradead.org/activesyncd.git/blob/HEAD:/syncevolution/README
The backend itself already supports all four data categories, but only
calendar events are supported by the EAS library at this time.
There's also quite a bit of work left. The EAS library doesn't allow
distinguishing between different error scenarios, so right now
everything, including temporary network errors, forces a slow sync in
the next sync session.
I went for the simplest possible approach. Batching multiple changes to
the server side into one final call would be useful. It's easy enough
for deletes, but a bit harder for adds, because the Synthesis engine
needs to know the final ID. This can be solved by assigning a temporary
ID and reporting the final one later.
Question to Mobica: right now, the client_id is not set at all by the
SyncEvolution backend. Will your code handle that?
--
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.
1:20 p.m.
On So, 2011-06-19 at 15:17 +0200, Patrick Ohly wrote:
See the README for more instructions:
http://git.infradead.org/activesyncd.git/blob/HEAD:/syncevolution/README
29 Configure access to the server:
30 $ syncevolution --configure \
31 username=<ActiveSync account ID, as decimal or hexadecimal
value> \
32 addressbook/backend=eas-contacts \
33 calendar/backends=eas-events \
34 todo/backends=eas-todos \
35 memo/backends=eas-memos \
36 source-config@exchange
This will be simplified in the future by providing a configuration
template for Exchange which will have the "backend" values pre-set.
It'll be of "peerType=ActiveSync", which will tell the traditional UIs
which don't know about the username=account_id semantic (GTK and QML)
that they can and should ignore this template.
--
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.
2:22 p.m.
On Sun, 2011-06-19 at 15:17 +0200, Patrick Ohly wrote:
I only tried compilation inside SyncEvolution. I haven't even tried to
run it at this point. I'll try to find the time for that tomorrow.
I tried to fix up compilation within the activesyncd repository, which I
suspect is going to be easier for development and packaging for now.
The patch below is a start, but it fails to link:
/usr/bin/ld: cannot find -lsynthesissdk
Perhaps this is just an issue with the Fedora 15 packaging of
syncevolution? It seems to list -lsynthesissdk in the output of
'pkg-config --libs syncevolution' but that library doesn't *exist*.
(Note also the 'Ick' comment about the backend dir. Am I missing
something, or should that be added to syncevolution.pc?)
diff --git a/Makefile.am b/Makefile.am
index cbf1161..1feec1a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,4 +1,4 @@
ACLOCAL_AMFLAGS = -I m4
#SUBDIRS = libeasmail/tests
-SUBDIRS = . logger libeassync/src libeasmail/src eas-daemon/libeas eas-daemon/src
eas-daemon/tests check_tests camel
+SUBDIRS = . logger libeassync/src libeasmail/src eas-daemon/libeas eas-daemon/src
eas-daemon/tests check_tests camel syncevolution
EXTRA_DIST = autogen.sh
diff --git a/configure.ac b/configure.ac
index f4049d3..f479813 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,10 +54,15 @@ PKG_CHECK_MODULES(WBXML, libwbxml2 >= 0.11)
PKG_CHECK_MODULES(LIBICAL, libical)
PKG_CHECK_MODULES(CAMEL, camel-provider-1.2)
PKG_CHECK_MODULES(LIBEBACKEND, libebackend-1.2)
+PKG_CHECK_MODULES(SYNCEVOLUTION, syncevolution)
camel_providerdir=`$PKG_CONFIG --variable=camel_providerdir camel-provider-1.2`
AC_SUBST(camel_providerdir)
+# Ick. Shouldn't this be in syncevolution.pc like camel_providerdir above ?
+syncevo_backenddir=$libdir/syncevolution/backends
+AC_SUBST(syncevo_backenddir)
+
AC_CONFIG_FILES([
Makefile
eas-daemon/data/Makefile
@@ -69,6 +74,7 @@ AC_CONFIG_FILES([
check_tests/Makefile
logger/Makefile
camel/Makefile
+ syncevolution/Makefile
])
diff --git a/syncevolution/Makefile.am b/syncevolution/Makefile.am
index 73fd343..2f0bc81 100644
--- a/syncevolution/Makefile.am
+++ b/syncevolution/Makefile.am
@@ -2,13 +2,15 @@ AM_CPPFLAGS = $(SYNCEVOLUTION_CFLAGS) -I$(top_srcdir)/test
$(BACKEND_CPPFLAGS)
EXTRA_DIST = configure-sub.in
+backenddir = $(syncevo_backenddir)
+
SYNCSOURCES = syncactivesync.la
MOSTLYCLEANFILES = $(SYNCSOURCES)
-if ENABLE_MODULES
+#if ENABLE_MODULES
backend_LTLIBRARIES = $(SYNCSOURCES)
-else
-noinst_LTLIBRARIES = $(SYNCSOURCES)
-endif
+#else
+#noinst_LTLIBRARIES = $(SYNCSOURCES)
+#endif
MAINTAINERCLEANFILES = Makefile.in
--
dwmw2
6:39 p.m.
On So, 2011-06-19 at 15:22 +0100, David Woodhouse wrote:
On Sun, 2011-06-19 at 15:17 +0200, Patrick Ohly wrote:
>
> I only tried compilation inside SyncEvolution. I haven't even tried to
> run it at this point. I'll try to find the time for that tomorrow.
I tried to fix up compilation within the activesyncd repository, which I
suspect is going to be easier for development and packaging for now.
The patch below is a start, but it fails to link:
/usr/bin/ld: cannot find -lsynthesissdk
Perhaps this is just an issue with the Fedora 15 packaging of
syncevolution? It seems to list -lsynthesissdk in the output of
'pkg-config --libs syncevolution' but that library doesn't *exist*.
Probably.
Beware that you need the very latest SyncEvolution source code anyway,
which is not in Fedora. I'll package it for MeeGo tomorrow.
(Note also the 'Ick' comment about the backend dir. Am I
missing
something, or should that be added to syncevolution.pc?)
Sure, can be added. Will do.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
10:47 p.m.
On Sun, 2011-06-19 at 20:39 +0200, Patrick Ohly wrote:
Beware that you need the very latest SyncEvolution source code
anyway,
which is not in Fedora. I'll package it for MeeGo tomorrow.
Please could you link it into the home:dwmw2:evo project that we're
doing our test builds in:
osc linkpac $YOURPROJECT syncevolution home:dwmw2:evo
--
dwmw2
1:03 p.m.
On So, 2011-06-19 at 23:47 +0100, David Woodhouse wrote:
On Sun, 2011-06-19 at 20:39 +0200, Patrick Ohly wrote:
> Beware that you need the very latest SyncEvolution source code anyway,
> which is not in Fedora. I'll package it for MeeGo tomorrow.
Please could you link it into the home:dwmw2:evo project that we're
doing our test builds in:
osc linkpac $YOURPROJECT syncevolution home:dwmw2:evo
SyncEvolution is maintained in "eds", so that would be:
osc linkpac eds syncevolution home:dwmw2:evo
I have created the link. What you need for the ActiveSync backend is
SyncEvolution >= 1.1.99.4 + 20110620. I'm not tagging new versions for
each snapshot.
--
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:09 a.m.
On Mon, 2011-06-20 at 15:03 +0200, Patrick Ohly wrote:
SyncEvolution is maintained in "eds", so that would be:
osc linkpac eds syncevolution home:dwmw2:evo
I have created the link. What you need for the ActiveSync backend is
SyncEvolution >= 1.1.99.4 + 20110620. I'm not tagging new versions for
each snapshot.
Thanks. Still doesn't build on my MeeGo box though, since the
syncevolution.pc file still references a -lsynthesis-sdk that doesn't
exist.
libtool: link: g++ -shared -nostdlib /usr/lib/gcc/i586-meego-linux/4.5.1/../../../crti.o
/usr/lib/gcc/i586-meego-linux/4.5.1/crtbeginS.o
.libs/syncactivesync_la-ActiveSyncSource.o -lsyncevolution -lsynthesissdk -lsmltk
-lsynthesis -L/usr/lib/gcc/i586-meego-linux/4.5.1
-L/usr/lib/gcc/i586-meego-linux/4.5.1/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i586-meego-linux/4.5.1/crtendS.o
/usr/lib/gcc/i586-meego-linux/4.5.1/../../../crtn.o -Wl,-soname -Wl,syncactivesync.so
-o .libs/syncactivesync.so
/usr/bin/ld: cannot find -lsynthesissdk
collect2: ld returned 1 exit status
make[2]: *** [syncactivesync.la] Error 1
make[2]: Leaving directory `/home/dwoodhou/activesyncd/syncevolution'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dwoodhou/activesyncd'
make: *** [all] Error 2
[dwoodhou@dwoodhou-meego activesyncd]$ rpm -q --changelog syncevolution | head -6
* Mon Jun 20 2011 Patrick Ohly <patrick.ohly(a)intel.com> - 1.1.99.4
- source code changes:
- improved testing and WebDAV error handling
- added support for out-of-tree ActiveSync backend
- syncevo-dbus-server: local configs should be 'present' (temporary solution for
BMC #19488)
[dwoodhou@dwoodhou-meego activesyncd]$ pkg-config --libs syncevolution
-lsyncevolution -lsynthesissdk -lsmltk -lsynthesis
[dwoodhou@dwoodhou-meego activesyncd]$ ls -l /usr/lib/libsynthesis*
lrwxrwxrwx 1 root root 21 2011-06-21 00:53 /usr/lib/libsynthesis.so ->
libsynthesis.so.0.5.0
lrwxrwxrwx 1 root root 21 2011-06-21 00:47 /usr/lib/libsynthesis.so.0 ->
libsynthesis.so.0.5.0
-rwxr-xr-x 1 root root 1564160 2011-06-20 14:01 /usr/lib/libsynthesis.so.0.5.0
[dwoodhou@dwoodhou-meego activesyncd]$ rpm -ql syncevolution syncevolution-libs
syncevolution-devel | grep synthesissdk
[dwoodhou@dwoodhou-meego activesyncd]$ rpm -ql syncevolution syncevolution-libs
syncevolution-devel | head
--
dwmw2
4:13 p.m.
On Di, 2011-06-21 at 01:09 +0100, David Woodhouse wrote:
On Mon, 2011-06-20 at 15:03 +0200, Patrick Ohly wrote:
>
> SyncEvolution is maintained in "eds", so that would be:
>
> osc linkpac eds syncevolution home:dwmw2:evo
>
> I have created the link. What you need for the ActiveSync backend is
> SyncEvolution >= 1.1.99.4 + 20110620. I'm not tagging new versions for
> each snapshot.
Thanks. Still doesn't build on my MeeGo box though, since the
syncevolution.pc file still references a -lsynthesis-sdk that doesn't
exist.
Should be fixed in "eds:syncevolution" and thus your home dir. OBS magic
helpfully deleted all .a files, so I never noticed that the one .a which
is needed (because it contains stub code which is not shared) wasn't
packaged.
--
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:01 a.m.
On Tue, 2011-06-21 at 18:13 +0200, Patrick Ohly wrote:
Should be fixed in "eds:syncevolution" and thus your home
dir. OBS magic
helpfully deleted all .a files, so I never noticed that the one .a which
is needed (because it contains stub code which is not shared) wasn't
packaged.
That builds; thanks. What about $backenddir?
--
dwmw2
11:46 p.m.
On Wed, 2011-06-22 at 01:01 +0100, David Woodhouse wrote:
On Tue, 2011-06-21 at 18:13 +0200, Patrick Ohly wrote:
> Should be fixed in "eds:syncevolution" and thus your home dir. OBS magic
> helpfully deleted all .a files, so I never noticed that the one .a which
> is needed (because it contains stub code which is not shared) wasn't
> packaged.
That builds; thanks. What about $backenddir?
I've added it to SyncEvolution now. Just in case I also added
templatedir. This might come handy if we want to install an "ActiveSync"
config template from inside the activesyncd source code.
Regarding the activesyncd/syncevolution source: can we keep the
Makefile.am so that it works also in SyncEvolution? That's how I am
currently compiling. That means that any hacks, like hard-coding compile
flags, have to be in the activesyncd configure and that it needs to set
the ENABLE_ACTIVESYNC condition variable.
I have pushed two commits implementing that to master, admittedly
without testing as part of activesyncd. Please revert if it breaks
anything.
--
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:58 p.m.
On Tue, 2011-06-28 at 16:46 -0700, Patrick Ohly wrote:
I've added it to SyncEvolution now. Just in case I also added
templatedir. This might come handy if we want to install an
"ActiveSync" config template from inside the activesyncd source code.
Cool, thanks.
Regarding the activesyncd/syncevolution source: can we keep the
Makefile.am so that it works also in SyncEvolution?
How are you pulling in the libeassync headers/flags? This ought to be in
a pkgconfig file, right? I've just changed the Makefile.am to assume
that they are pulled in sensibly by pkgconfig in the SyncEvolution
build, and to hard-code them only if not.
Should I couple that with actually providing a .pc file for libeassync?
--
dwmw2
12:49 a.m.
On Wed, 2011-06-29 at 00:58 +0100, David Woodhouse wrote:
On Tue, 2011-06-28 at 16:46 -0700, Patrick Ohly wrote:
> Regarding the activesyncd/syncevolution source: can we keep the
> Makefile.am so that it works also in SyncEvolution?
How are you pulling in the libeassync headers/flags?
There is a PKG_CHECK_MODULES(EASSYNC) in configure-sub.in. Currently I
override the lack of a proper .pc by setting EASSYNC_CFLAGS and
EASSYNC_LIBS as configure variables.
This ought to be in
a pkgconfig file, right? I've just changed the Makefile.am to assume
that they are pulled in sensibly by pkgconfig in the SyncEvolution
build, and to hard-code them only if not.
Should I couple that with actually providing a .pc file for libeassync?
Yes, that would be the right solution.
--
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.
1:02 a.m.
On Tue, 2011-06-28 at 17:49 -0700, Patrick Ohly wrote:
> How are you pulling in the libeassync headers/flags?
There is a PKG_CHECK_MODULES(EASSYNC) in configure-sub.in. Currently I
override the lack of a proper .pc by setting EASSYNC_CFLAGS and
EASSYNC_LIBS as configure variables.
OK, so I haven't actually broken the build for you by 'assuming' that
they'll be set correctly in the SyncEvolution build?
> Should I couple that with actually providing a .pc file for
libeassync?
Yes, that would be the right solution.
Oh, I know it's the right solution. The question was more "Do I really
need to do this *now*, at 2am". I'm taking your above response as a
'no' :)
--
dwmw2
1:07 a.m.
On Wed, 2011-06-29 at 02:02 +0100, David Woodhouse wrote:
On Tue, 2011-06-28 at 17:49 -0700, Patrick Ohly wrote:
> > How are you pulling in the libeassync headers/flags?
>
> There is a PKG_CHECK_MODULES(EASSYNC) in configure-sub.in. Currently I
> override the lack of a proper .pc by setting EASSYNC_CFLAGS and
> EASSYNC_LIBS as configure variables.
OK, so I haven't actually broken the build for you by 'assuming' that
they'll be set correctly in the SyncEvolution build?
It was broken by removing the "if ENABLE_MODULES" check in Makefile.am
and latter by hard-coding compile flags there.
> > Should I couple that with actually providing a .pc file for
libeassync?
>
> Yes, that would be the right solution.
Oh, I know it's the right solution. The question was more "Do I really
need to do this *now*, at 2am". I'm taking your above response as a
'no' :)
Indeed, this is not important.
--
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.
4:43 p.m.
2011/6/19 Patrick Ohly <patrick.ohly(a)intel.com>
I have implemented an ActiveSync backend for the ActiveSync
implementation developed by Mobica. Code is currently in the activesyncd
git repo.
Interesting. From what I remember, ActiveSync was not released by Microsoft
under the Open Specification Promise and the specs were toxic for free
software. Is this implementation the result of 'looking the packets on the
cable' like samba does or something changed and Microsoft now licenses this
set of specs under a license compatible with free software?
thanks,
stef
11:13 p.m.
On Tue, 2011-06-21 at 09:43 -0700, Stefano Maffulli wrote:
Interesting. From what I remember, ActiveSync was not released by
Microsoft under the Open Specification Promise and the specs were
toxic for free software. Is this implementation the result of 'looking
the packets on the cable' like samba does or something changed and
Microsoft now licenses this set of specs under a license compatible
with free software?
The latter. The documents (MS-ASCMD et al) now have the following
"Intellectual Property Rights Notice":
- Copyrights. This documentation is covered by Microsoft copyrights.
Regardless of any other terms that are contained in the terms of use
for the Microsoft website that hosts this documentation, you may make
copies of it in order to develop implementations of the technologies
described in the Open Specifications and may distribute portions of
it in your implementations using these technologies or your
documentation as necessary to properly document the implementation.
You may also distribute in your implementation, with or without
modification, any schema, IDL’s, or code samples that are included in
the documentation. This permission also applies to any documents that
are referenced in the Open Specifications.
- No Trade Secrets. Microsoft does not claim any trade secret rights in
this documentation.
- Patents. Microsoft has patents that may cover your implementations of
the technologies described in the Open Specifications. Neither this
notice nor Microsoft's delivery of the documentation grants any
licenses under those or any other Microsoft patents.
So there is nothing to worry about on the copyright/licensing front.
I've heard rumours about patents, and companies allegedly paying for
licensing deals covering parts of the ActiveSync spec. However, having
seen *our* implementation, I am confident that there is nothing here
which could be patented even under the horribly corrupt and widely
abused US system. All we're doing is saying to the server "tell me what
happened since my last bookmark, and give me a new bookmark reflecting
the current state". It's basically the same as IMAP CONDSTORE/QRESYNC
and countless other obvious things before it.
So perhaps the rumoured patents cover the undocumented older versions of
the protocol, or cover things that we have not needed to implement to
provide basic email/calendar/addressbook functionality, or cover things
which are implemented on the server side (such as how they keep track of
those 'bookmarks' for various clients).
Either way, it seems that if anyone does try to claim that you are
infringing on their patents when using *this* code, they are likely
committing the criminal offence of fraud and you should report that to
your local police immediately.
--
dwmw2
2:55 p.m.
2011/6/21 David Woodhouse <dwmw2(a)infradead.org>
So there is nothing to worry about on the copyright/licensing front.
So it seems.
Either way, it seems that if anyone does try to claim that you are
infringing on their patents when using *this* code, they are likely
committing the criminal offence of fraud and you should report that to
your local police immediately.
I'm not aware of any patent trolling activity around ActiveSync. I was just
wondering if Microsoft had clearly given a blanket protection from their
patents to free software implementation of ActiveSync, like they did with
Samba. According to what you reported this is not the case. In any case, the
client side the protocol seems to be safe from patent claims because it does
trivial things.
Thank you for the David,
/stef
11:39 p.m.
Andy,
have you seen the question below? Does the libeassync depend on
non-empty client IDs?
Bye, Patrick
On Sun, 2011-06-19 at 15:17 +0200, Patrick Ohly wrote:
Hello all!
I have implemented an ActiveSync backend for the ActiveSync
implementation developed by Mobica. Code is currently in the activesyncd
git repo. It is hosted there because the activesyncd library API is not
stable yet. Long term it'll probably move back to SyncEvolution.
I only tried compilation inside SyncEvolution. I haven't even tried to
run it at this point. I'll try to find the time for that tomorrow.
See the README for more instructions:
http://git.infradead.org/activesyncd.git/blob/HEAD:/syncevolution/README
The backend itself already supports all four data categories, but only
calendar events are supported by the EAS library at this time.
There's also quite a bit of work left. The EAS library doesn't allow
distinguishing between different error scenarios, so right now
everything, including temporary network errors, forces a slow sync in
the next sync session.
I went for the simplest possible approach. Batching multiple changes to
the server side into one final call would be useful. It's easy enough
for deletes, but a bit harder for adds, because the Synthesis engine
needs to know the final ID. This can be solved by assigning a temporary
ID and reporting the final one later.
Question to Mobica: right now, the client_id is not set at all by the
SyncEvolution backend. Will your code handle that?
2:41 p.m.
Hi Patrick,
Sorry I've not replied to this before - currently , the libeassync
expects non-empty client id's but it is trivial for me to do a check
and add a randomly generated client ID. I'm just starting to look at
this area, and get it working, so will add that functionality as and
when I get it all up and running.
cheers,
Andy
On 26/06/11 00:39, Patrick Ohly wrote:
Andy,
have you seen the question below? Does the libeassync depend on
non-empty client IDs?
Bye, Patrick
On Sun, 2011-06-19 at 15:17 +0200, Patrick Ohly wrote:
> Hello all!
>
> I have implemented an ActiveSync backend for the ActiveSync
> implementation developed by Mobica. Code is currently in the activesyncd
> git repo. It is hosted there because the activesyncd library API is not
> stable yet. Long term it'll probably move back to SyncEvolution.
>
> I only tried compilation inside SyncEvolution. I haven't even tried to
> run it at this point. I'll try to find the time for that tomorrow.
>
> See the README for more instructions:
> http://git.infradead.org/activesyncd.git/blob/HEAD:/syncevolution/README
>
> The backend itself already supports all four data categories, but only
> calendar events are supported by the EAS library at this time.
>
> There's also quite a bit of work left. The EAS library doesn't allow
> distinguishing between different error scenarios, so right now
> everything, including temporary network errors, forces a slow sync in
> the next sync session.
>
> I went for the simplest possible approach. Batching multiple changes to
> the server side into one final call would be useful. It's easy enough
> for deletes, but a bit harder for adds, because the Synthesis engine
> needs to know the final ID. This can be solved by assigning a temporary
> ID and reporting the final one later.
>
> Question to Mobica: right now, the client_id is not set at all by the
> SyncEvolution backend. Will your code handle that?
>
3816
days inactive
3826
days old
syncevolution@synevolution.org
18 comments
4 participants
participants (4)
-
Andy Gould -
David Woodhouse -
Patrick Ohly -
Stefano Maffulli