9:14 p.m.
Hi all!
I'm working on adding Ubuntu Online Accounts (UOA) support to
SyncEvolution, and I've several unrelated questions about it.
Code wise, is it fine if I modify the existing gSSO code, and add some
#ifdef so that it can work with UOA as well? Or is it preferrable if I
duplicate the whole backend, so that they can be used in parallel?
(obviously, signond a gsignond cannot be run at the same time in the
same user session; but it might be that on the same machine they both
run for different users, using different DEs)
I managed to build SyncEvolution with my changes; but when I run it I
get this error:
================
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 \
--print-databases backend=caldav \
username=gsso:24,google-caldav \
syncURL=https://apidata.googleusercontent.com/caldav/v2
caldav:
CalDAV: not enabled during compilation or not usable in the current
environment
================
And the same error if I try with carddav. I don't see any mention of
them in the configure log; how can I check if they are actually built or
if it's a runtime error?
Ciao,
Alberto
9:59 p.m.
On Mon, 2013-12-02 at 12:14 +0200, Alberto Mardegan wrote:
I'm working on adding Ubuntu Online Accounts (UOA) support to
SyncEvolution
Good to hear :-) I'm sure Ubuntu users will appreciate that.
Code wise, is it fine if I modify the existing gSSO code, and add
some
#ifdef so that it can work with UOA as well? Or is it preferrable if I
duplicate the whole backend, so that they can be used in parallel?
Please use ifdefs.
If there ever is a need to use them in parallel, then we can add
namespaces and compile the code twice, with different defines.
I managed to build SyncEvolution with my changes; but when I run it
I
get this error:
================
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 \
--print-databases backend=caldav \
username=gsso:24,google-caldav \
syncURL=https://apidata.googleusercontent.com/caldav/v2
caldav:
CalDAV: not enabled during compilation or not usable in the current
environment
================
And the same error if I try with carddav. I don't see any mention of
them in the configure log; how can I check if they are actually built or
if it's a runtime error?
You need to use --enable-dav. The configure prints a summary at the end
which includes information about enabled backends.
If it gets built, then check that loading the backends worked.
"syncevolution --daemon=no --version" shows the loaded backends.
I personally compile with "--disable-dynamic --enable-static", because
then I get binaries which I can run directly in gdb.
The README.rst documents environment variables for running SyncEvolution
without "make install", which may also be useful.
--
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.
Hi,
On 12/02/2013 12:59 PM, Patrick Ohly wrote:
> Code wise, is it fine if I modify the existing gSSO code, and add
some
> #ifdef so that it can work with UOA as well? Or is it preferrable if I
> duplicate the whole backend, so that they can be used in parallel?
Please use ifdefs.
If there ever is a need to use them in parallel, then we can add
namespaces and compile the code twice, with different defines.
OK. I just hope that gSSO doesn't continue diverging. :-)
[...]
You need to use --enable-dav. The configure prints a summary at the
end
which includes information about enabled backends.
Cool! I finally got it working. I will clean up the code and submit
patches to bugzilla in the coming days.
One question (please bear in mind that I don't know much about SE, so I
might be missing something here): why do we need to configure the
account in SyncEvolution?
Couldn't SE simply enumerate all the enabled accounts it supports, and
synchronize them?
Ciao,
Alberto
12:55 a.m.
On Mon, 2013-12-02 at 15:01 +0200, Alberto Mardegan wrote:
One question (please bear in mind that I don't know much about
SE, so I
might be missing something here): why do we need to configure the
account in SyncEvolution?
Primarily because the necessary code hasn't been written yet.
Couldn't SE simply enumerate all the enabled accounts it
supports, and
synchronize them?
Yes, the permanently running syncevo-dbus-server could host such a
listener and trigger the necessary actions.
However, what exactly those actions are needs to be defined and/or
configured. For example, should it also create local databases? In EDS
or Akonadi? Should it sync all remote databases that it gets access to,
without asking the user?
At the technical level, some more things need to be sorted out. What
shall happen when a sync is running and the corresponding account gets
removed? Currently SyncEvolution prevents that by only allowing config
changes when no sync runs.
Should there still be a sync and target config? We might be able to get
all information from the account system and then could pretend to have a
traditional config which never really exists on disk. The advantage of a
real configuration is that some additional config settings (log level,
backup) might only be possible there.
However, the ~/.config dir of the sync config is also (ab)used for
storing meta data about the sync. Where would that data live then?
--
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:53 a.m.
Hi Alberto,
On 2.12.2013 12:14, Alberto Mardegan wrote:
(obviously, signond a gsignond cannot be run at the same time in the
same user session; but it might be that on the same machine they both
run for different users, using different DEs)
Although I have not tested, it should actually work, because namespaces
for the dbus interfaces are different. On purpose, client library APIs
are as close as possible, but use just different location for the
headers, so just changing pkg-config module name should be enough switch
over (in addition to some of the API changes).
Not that there would be much point in running the two in parallel...
12:07 a.m.
Hi!
FYI, I filed the patch here:
https://bugs.freedesktop.org/show_bug.cgi?id=72263
Note that it doesn't address the issue we are discussing below (that
will, if ever, come as a separate patch).
On 12/02/2013 03:55 PM, Patrick Ohly wrote:
> Couldn't SE simply enumerate all the enabled accounts it
supports, and
> synchronize them?
Yes, the permanently running syncevo-dbus-server could host such a
listener and trigger the necessary actions.
Right.
However, what exactly those actions are needs to be defined and/or
configured. For example, should it also create local databases? In EDS
or Akonadi? Should it sync all remote databases that it gets access to,
without asking the user?
I guess it mostly depend on how the synchronization is going to work in
the given platform. If there is some UI to configure the
synchronization, probably it should be its responsibility to create the
databases. If there isn't, then it may be that the consumer applications
(those reading from the local DBs) might be the ones to do that.
I'll try to get a clearer idea of what we want to do in Ubuntu. :-)
Ciao,
Alberto
9:42 p.m.
On Tue, 2013-12-03 at 15:07 +0200, Alberto Mardegan wrote:
Hi!
FYI, I filed the patch here:
https://bugs.freedesktop.org/show_bug.cgi?id=72263
Thanks a lot. I am considering including that in SyncEvolution 1.3.99.6
and also enable it when compiling binaries for download from
syncevolution.org.
I can enable GNOME Online Account support easily in these binaries. That
will work for Google CalDAV with GNOME >= 3.8 and Google CardDAV with
GNOME >= 3.10. But does Ubuntu still have the GNOME Online Accounts UI?
I noticed that Quantal has the packages, but I haven't tried to use
them.
Enabling Ubuntu Online Accounts did not work immediately, because my
compile platform (Quantal) was too old. Would it be worthwhile to invest
more work into this?
--
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.
10:13 p.m.
On 12/04/2013 12:42 PM, Patrick Ohly wrote:
On Tue, 2013-12-03 at 15:07 +0200, Alberto Mardegan wrote:
> Hi!
> FYI, I filed the patch here:
> https://bugs.freedesktop.org/show_bug.cgi?id=72263
Thanks a lot. I am considering including that in SyncEvolution 1.3.99.6
and also enable it when compiling binaries for download from
syncevolution.org.
I can enable GNOME Online Account support easily in these binaries. That
will work for Google CalDAV with GNOME >= 3.8 and Google CardDAV with
GNOME >= 3.10. But does Ubuntu still have the GNOME Online Accounts UI?
I noticed that Quantal has the packages, but I haven't tried to use
them.
Yes, GOA is packaged in Ubuntu and will be visible in the control
center, if you use the GNOME 3 session.
Enabling Ubuntu Online Accounts did not work immediately, because my
compile platform (Quantal) was too old. Would it be worthwhile to invest
more work into this?
No, I think that the only sensible thing to do is add the required
package versions in the configure.ac bits (I wrote the needed versions
in the bug report), and do not bother supporting older releases;
otherwise the delta between UOA and gSSO would get much bigger.
BTW, Quantal is more than 1 year old now, and not being an LTS I'd
recommend upgrading. :-)
Ciao,
Alberto
11:03 p.m.
On Wed, 2013-12-04 at 13:13 +0200, Alberto Mardegan wrote:
On 12/04/2013 12:42 PM, Patrick Ohly wrote:
> I can enable GNOME Online Account support easily in these binaries. That
> will work for Google CalDAV with GNOME >= 3.8 and Google CardDAV with
> GNOME >= 3.10. But does Ubuntu still have the GNOME Online Accounts UI?
> I noticed that Quantal has the packages, but I haven't tried to use
> them.
Yes, GOA is packaged in Ubuntu and will be visible in the control
center, if you use the GNOME 3 session.
But that is not the default, right?
> Enabling Ubuntu Online Accounts did not work immediately,
because my
> compile platform (Quantal) was too old. Would it be worthwhile to invest
> more work into this?
No, I think that the only sensible thing to do is add the required
package versions in the configure.ac bits (I wrote the needed versions
in the bug report), and do not bother supporting older releases;
otherwise the delta between UOA and gSSO would get much bigger.
Let's rephrase ;-) Would it be useful for Ubuntu users to support a more
recent Ubuntu distro, and if so, which one?
BTW, Quantal is more than 1 year old now, and not being an LTS
I'd
recommend upgrading. :-)
It's really only used for compilation, so I'm not concerned about the
lack of support. There is no more recent LTS yet, and downgrading
wouldn't give me the EDS >= 3.6 libraries.
--
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:12 p.m.
On 12/04/2013 02:03 PM, Patrick Ohly wrote:
On Wed, 2013-12-04 at 13:13 +0200, Alberto Mardegan wrote:
> On 12/04/2013 12:42 PM, Patrick Ohly wrote:
>> I can enable GNOME Online Account support easily in these binaries. That
>> will work for Google CalDAV with GNOME >= 3.8 and Google CardDAV with
>> GNOME >= 3.10. But does Ubuntu still have the GNOME Online Accounts UI?
>> I noticed that Quantal has the packages, but I haven't tried to use
>> them.
>
> Yes, GOA is packaged in Ubuntu and will be visible in the control
> center, if you use the GNOME 3 session.
But that is not the default, right?
It's the default in the GNOME session. Under Unity, GOA is not visible.
>> Enabling Ubuntu Online Accounts did not work immediately,
because my
>> compile platform (Quantal) was too old. Would it be worthwhile to invest
>> more work into this?
>
> No, I think that the only sensible thing to do is add the required
> package versions in the configure.ac bits (I wrote the needed versions
> in the bug report), and do not bother supporting older releases;
> otherwise the delta between UOA and gSSO would get much bigger.
Let's rephrase ;-) Would it be useful for Ubuntu users to support a more
recent Ubuntu distro, and if so, which one?
I'm afraid I still don't get it :-)
If you are asking what's the target release for this work: it's
primarily driven by Ubuntu Touch, but could possibly land in the 14.04
LTS as well. I'm developing it in "Trusty".
Ciao,
Alberto
12:04 a.m.
On Thu, 2013-12-05 at 14:12 +0200, Alberto Mardegan wrote:
On 12/04/2013 02:03 PM, Patrick Ohly wrote:
> On Wed, 2013-12-04 at 13:13 +0200, Alberto Mardegan wrote:
>>> Enabling Ubuntu Online Accounts did not work immediately, because my
>>> compile platform (Quantal) was too old. Would it be worthwhile to invest
>>> more work into this?
>>
>> No, I think that the only sensible thing to do is add the required
>> package versions in the configure.ac bits (I wrote the needed versions
>> in the bug report), and do not bother supporting older releases;
>> otherwise the delta between UOA and gSSO would get much bigger.
>
> Let's rephrase ;-) Would it be useful for Ubuntu users to support a more
> recent Ubuntu distro, and if so, which one?
I'm afraid I still don't get it :-)
There are Ubuntu users who download and install binaries from
syncevolution.org, typically because these binaries are more recent than
the version they get from their current distro.
I see that as a service for users and a way to get testing in advance of
inclusion in a distro.
I can't compile SyncEvolution n times for different distros, that would
be too much work. Instead I try to provide archives that work across a
wide range of distros, usually by compiling on an old distro. But that
limits what kind of features I can enable.
It looks like enabling Ubuntu Online Accounts in these binaries will not
be easy, so I'll probably not do it.
--
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.
3209
days inactive
3212
days old
syncevolution@synevolution.org
10 comments
3 participants
participants (3)
-
Alberto Mardegan -
Jussi Laako -
Patrick Ohly