Re: [SyncEvolution] D-Bus server reorganization
by Patrick Ohly
On Fr, 2011-06-24 at 12:24 +0200, Murray Cumming wrote:
> On Fri, 2011-06-24 at 11:41 +0200, Patrick Ohly wrote:
> > commit 581339e3b2c0a4492a4c92d765af12a9158d85f6
> > Author: Murray Cumming <murrayc(a)murrayc.com>
> > Date: Wed Jun 15 11:08:43 2011 +0200
> >
> > dbus-server: Do not use NULL in C++ code.
> >
> > NULL does not meant the same thing in C as in C++. It can lead to
> > hard-to-debug problems.
> >
> > Why should NULL not be used? It can't be the (void *)0 definition as
> > in
> > C, but both 0 (the generic C++ null pointer) or g++'s __null [1]
> > should
> > be fine.
>
> Firstly, this is my commit, not Chris's. It's a pet thing of mine.
I know. I didn't mention it explicitly because of Author: field.
> > I personally like to use NULL because it makes C and C++ code more
> > consistent and as additional indicator that a type is a pointer.
>
> But NULL is not a pointer in C++. It is in C.
>
> > [1] http://gcc.gnu.org/onlinedocs/libstdc
> > ++/manual/bk01pt02ch04s03.html
>
> NULL is a particular problem when calling varargs functions, passing
> NULL as a sentinel, and then it's a hard one to debug. I personally
> prefer to clean all NULLs out of code to make it impossible for that to
> ever happen.
In other words, NULL works as long as it is defined to __null but fails
in this case on 32 bit systems when it is 0? And you prefer to write
(void *)0 (when needed) or just 0 (when not)?
Okay, I see how that can be tricky because using NULL is a portability
problem: works on our test platform, may fail elsewhere.
> I believe this is why C++0x has nullptr:
> http://en.wikipedia.org/wiki/C%2B%2B0x#Null_pointer_constant
>
> If you don't like the change, we don't have to have it. It's a very
> minor thing.
I'm undecided ;-) If we ban NULL, we would have to do it consistently.
--
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 years, 6 months
[SyncEvolution] D-Bus server reorganization
by Patrick Ohly
Hello!
Chris is working on reorganizing and (eventually) rewriting the
syncevo-dbus-server. The first part is splitting up the large
syncevo-dbus-server.cpp into more manageable pieces.
Chris, before work starts on more fundamental design changes, can you
outline what you want to do and how? That's the big picture.
Part of the details is coding style. It's poorly documented in the
HACKING document (basically just referencing another document) and not
followed consistently. I probably need to have a look at the code that
you are writing to determine whether there's anything that I'd like to
have done differently.
One thing caught my eye:
commit 581339e3b2c0a4492a4c92d765af12a9158d85f6
Author: Murray Cumming <murrayc(a)murrayc.com>
Date: Wed Jun 15 11:08:43 2011 +0200
dbus-server: Do not use NULL in C++ code.
NULL does not meant the same thing in C as in C++. It can lead to
hard-to-debug problems.
Why should NULL not be used? It can't be the (void *)0 definition as in
C, but both 0 (the generic C++ null pointer) or g++'s __null [1] should
be fine.
I personally like to use NULL because it makes C and C++ code more
consistent and as additional indicator that a type is a pointer.
[1] http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt02ch04s03.html
--
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 years, 6 months
Re: [SyncEvolution] Running test-dbus.py and dbus_unittest
by Patrick Ohly
On Do, 2011-06-23 at 16:57 +0200, Chris Kühl wrote:
> Ok, I did this and it seems to sync fine after starting the
> dbus-http-server.
You shouldn't have to start it. test-dbus.py itself (re)starts the
daemon for each test.
> To be explicit here is what I'm doing step-by-step...
>
> 1) From the hacking document, I'm building using make ./autogen.sh
> && ./configure
> --with-synthesis-src=/home/chris/checkout/meego/libsynthesis/
> --enable-dbus-service --disable-shared --enable-libcurl
> --enable-unit-tests --enable-developer-mode && make -j4
>
> 2) I then install to /usr/local/. (I'm aware one should be able to run
> the static binary from the source tree. I'll do this once I'm confident
> things are working.)
>
> 3) Add a D-Bus-Testing address book in evolution and make sure my
> Memotoo account works.
>
> 4) Run syncevolution --configure --template Memotoo username=<your
> username> password=<your password> database=D-Bus-Testing dbus_unittest
> addressbook
>
> 6) Run syncevo-http-server http://localhost:9000/syncevolution &
>
> 7) Test that it's working using syncevolution dbus_unittest (The failed
> but told me how to fix it)
>
> 8) Change the server variable in test/test-dbus.py
> to /usr/local/libexec/syncevo-dbus-server
You should be able to avoid this by setting your PATH variable so that
it contains your self-compiled syncevo-dbus-server.
> 9) Go into the test folder and run ./test-dbus.py
>
> Does this seem correct?
I'm puzzled by the need to start the daemon manually.
> When running ./test-dbus.py (from where I branched, commit cfa5f08a31c),
> the test finishes without giving me useful results other than the final
> tally. I was expecting a report of some kind. The end of the output to
> the console looks like this...
There should be an error report for each failed test. Use test-dbus.py
-v for more information as tests are run. This is standard Python unit
testing.
> =========================================================================
> server output:
> [INFO] /usr/local/libexec/syncevo-dbus-server: ready to run
>
> Changes applied during synchronization:
> +---------------|-----------------------|-----------------------|-CON-+
> | | LOCAL | REMOTE | FLI |
> | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
> +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> | addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
> +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> | start Wed Jun 22 16:27:06 2011, duration 0:00min |
> | fatal error (remote, status 500) |
> +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> First ERROR encountered: error code from SyncEvolution fatal error
> (remote, status 500): addressbook: addressbook: no such address book:
> 'SyncEvolution_Test_addressbook_1'
This is part of the output for one failed tests. Scroll up to see which
one. Output for a failed test can be very large, because it includes
dumps of the syncevo-dbus-server stdout and from dbus-monitor.
> Are there other script to run or test sources to create for this to
> succeed?
The nightly testing turns this output into HTML, but you don't need
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.
9 years, 6 months
[SyncEvolution] SyncEvolution <-> Memotoo: additional X- chat extensions
by Patrick Ohly
Hello Thomas!
I recently extended our test data to fully cover all chat extensions
possible used by [Sync]Evolution and found that the new ones, in
contrast to those that we discussed a while back, are not stored on the
server. Perhaps you can add them?
X-GADUGADU
X-JABBER
X-MSN
X-SIP
X-SKYPE
X-GROUPWISE
In the meantime I'll ignore the data loss in synccompare, to keep the
tests passing.
--
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 years, 6 months
[SyncEvolution] [PATCHES] hijack error 404 to 401 when appropriate (2nd take)
by Salvatore Iovene
Hi,
please review the attached patches.
-Salvatore.
commit cdeddefc56797e46ec087a980a72f5670e6df882
Author: Salvatore Iovene <salvatore.iovene(a)linux.intel.com>
WebDavSource.cpp: hijack error 404 to 401 when appropriate.
If we get a 404 error while contacting the server, it might mean
that the username was wrong, so the server gave us a not found
error. It's better to let the user know that, because we don't
have a clear heuristic to determin whether this might have been
a true 404 error.
The convertion of 404 errors to 401 should happen only if the URL
we're trying to open is one in which it was us who injected the
username into the URL. This was achieved by removing the username
injection from the context creation code, and moving it into the
loop that does the autodiscovery, adding it path by path as it
was necessary.
Notice: this required NeonCXX to be aware of the "%u" semantic,
something I'm not completely comfortable with.
See also: https://bugs.meego.com/show_bug.cgi?id=17862
commit 8c55193d34400a2e94089d9fa2e750866c491515
Author: Salvatore Iovene <salvatore.iovene(a)linux.intel.com>
NeonCXX: don't trust libneon's escape and unescape functions.
commit b700c67b0c8500d673a2e3fa08445a4bc60f7996
Author: Salvatore Iovene <salvatore.iovene(a)linux.intel.com>
NeonCXX: rename check to checkError.
Using a name that gives better context.
--
Salvatore Iovene <salvatore.iovene(a)linux.intel.com>
Linux Software Engineer
Intel Open Source Technology Center, Finland
Tel.: +358504804026
9 years, 6 months
[SyncEvolution] Usage of syncevolution 1.1.1
by Laurent Emil
Hi all,
I wanna use sqlite as backend for data synchronisation instead of
syncevolution DB . How can I do that ? where should i modify in code or in
file configuration ?
also How can i get the xml messages exchanged between the syncevolution
client and the server ( Funambol server for example ) ? I mean explicit xml
messages not the logs detailed syncevolution-log.html ?
Regards.
9 years, 6 months
Re: [SyncEvolution] [MeeGo-community] nightly testing of SyncEvolution: move to meego.com server?
by Patrick Ohly
On Mo, 2011-05-16 at 20:11 +0100, David Greaves wrote:
> On 10/05/11 15:57, Foster, Dawn M wrote:
> >
> > On May 10, 2011, at 7:33 AM, Patrick Ohly wrote:
> >
> >> I've been told that meego.com has such hosting facilities. Is there a
> >> chance to move the testing to such a machine? Who can decide that?
> >>
> >
> > Talk to Adam Gretzinger (MeeGo sysadmin) - he should be able to
> > help you move it to a MeeGo server at OSU.
> >
> > Adam - we need a better process for requesting new infrastructure.
> > Do we have something like this for IT requests?
> > http://wiki.meego.com/Gitorious_guidelines#Adding_a_new_project_to_meego....
> > http://wiki.meego.com/Mailing_list_guidelines#Requesting_a_New_Mailing_List
>
> Sorry for the delayed reply:
> http://wiki.meego.com/Web_infrastructure
>
> http://wiki.meego.com/Web_infrastructure/Processes
Due to my vacation and the ensuing backlog this took a back seat for a
while. I've created a request as suggested:
https://bugs.meego.com/show_bug.cgi?id=19662
Dawn, Adam, if Adam is the one who'll help me with that, then next week
would be a good time to discuss it and perhaps start, if approval can be
obtained that quickly. I'll be on site then. Sorry for the short notice.
--
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 years, 6 months
[SyncEvolution] configuration parameters: command line update
by Patrick Ohly
Hello!
I'd like to solicit some feedback about configuring local sync, in
particular command line options for it. I'm still debating this with
myself, so consider the following email as "thinking aloud"...
As you might remember from the "local sync" mail thread, local sync uses
two configurations (using a "foo" server implementing some protocol
"bar" as example):
1. "source" config @foo defines sources which access "foo" using
the "bar" protocol; source-config@foo provides additional
per-peer settings like a URL or username/password
2. "sync" config foo has syncURL=local://@foo and does a sync
involving local databases (the same ones also used with other
peers) and the databases accessible via @foo
The original plan was to avoid the need for the source-config@foo
settings. But that neglected that credentials for "foo" should be tried
to the @foo context, instead of putting them elsewhere, and that there
was no other property which could have been used for the URL, to name
just one example.
This setup with two configs leads to two usability problems:
* How can such a config be created from a template? "syncevolution
--configure foo" would be nice.
* How can properties of both contexts be modified in a single
command? This is necessary for the single configure command
above and for running a sync.
Related to this is the question:
* How can multiple source properties be set in a single command?
Not being able to do that has made the instructions for
configuring SyncEvolution as a server unnecessarily complex.
Syntax for property values
==========================
Currently there is "--[sync|source]-property <property>=<value>".
<property> is the name of one of the builtin properties. I can imagine
extending this syntax as follows:
[<config>/]<property>[/<source>]=<value> (syntax I)
where <config> is a configuration name (which may contain @ signs) and
<source> is a source name (like "addressbook"). The rational for
introducing the slash as separator is that neither config nor source
names are allowed to contain it.
Examples:
evolutionsource=My Address Boook
evolutionsource/addressbook=My Address Book
@foo/evolutionsource/addressbook=Foo's Address Book
The drawback is that splitting the left side of the assignment is
ambiguous. In "foo/bar", either "foo" or "bar" could be the property
name. This can only be decided when property names are well-known. Typos
would break this detection, leading to bad error messages.
So perhaps the following syntax would be better:
[<source>/]<property>[@<config>]=<value> (syntax II)
The ordering of source, property and config is more natural:
addressbook/evolutionsource=My Address Book
syncURL@foo=local://@foo
But now the meaning of @ is overloaded:
syncURL@source-config@foo=Foo's URL
That is not a problem for a syntax parser, but less readable. The
ambiguity is resolved by declaring that @foo always a context.
I prefer the second syntax. Any other opinions?
As before, unqualified properties apply to all sources and all configs.
Templates for local sync
========================
The current set of templates provide properties for just one
configuration, the one which uses SyncML to talk to a server or a
client. Creating a local sync involves creating two configs.
There is no 1:1 mapping between the two. It is possible to define the
@foo sources, then synchronize them with a) the @default sources with
foo@default and b) with a second set of sources in @bar config with
foo@bar.
In the "syncevolution --configure foo" invocation, "foo" is the name of
the sync config. But what is the name of the source config? I propose
the following heuristic:
* if syncURL=local:// (no explicit context): use @foo for peer
name foo[@context]
* if syncURL=local://@bar: use @bar
That way a command line user still has the chance to override the source
context name, while the right thing will happen by default. Examples:
syncevolution --configure \
--sync-property username=xyz \
--sync-property password=abc \
foo
=> create or update @foo and foo, setting username/password in both
because they apply to both contexts
syncevolution --configure \
--sync-property syncURL=local://@bar \
foo
=> create or update @bar and foo; credentials must have been set in
@bar before
A template for "foo" then might look like this:
--------------------
=== template.ini ===
fingerprint = Foo Server
description = sync with Foo using protocol Bar
=== config.ini ===
PeerIsClient = 1
syncURL = local://
=== sources/addressbook/config.ini ===
sync = two-way
uri = addressbook
=== config.ini@source-config@foo ===
syncURL = http://foo.com/
=== sources/addressbook/config.ini@foo ===
uri = /contacts
type = Bar Protocol
--------------------
In the D-Bus interface, this would be returned by GetConfig() with "" as
key for "config.ini", "source-config@foo" for config.ini inside the
source-config@foo config, "sources/addressbook" for
sources/addressbook/config.ini and sources/addressbook@foo for
sources/addressbook/config.ini@foo.
My hope is that sync-ui will simply preserve these additional entries in
the hash. When it does a "SetConfig()" call with the modified hash
(credentials inserted, sync mode for "adddressbook" set), these
additional entries tell the syncevo-dbus-server to do its magic and also
configure the @foo context. The advantage is that no or only minimal
changes to sync-ui and D-Bus interface will be needed.
The drawback is that this additional magic increases the complexity. For
example, SetConfig() is called for the "foo" config, but suddenly ends
up modifying a different config.
Password handling in local sync
===============================
Credentials in the sync config are not needed for the sync itself,
because the peer is part of the same process. But users and frontends
like the GTK sync-ui are used to setting credentials in the sync config.
Therefore I suggest that local sync should always apply sync credentials
to the context it is synchronizing with, if they are set in the sync
config. If they are empty, the values from the source config are used.
Make --sync-property/--source-property optional
===============================================
A purely cosmetic change. It has irked me for a long time that the
command line was not able to determine automatically what username=foo
means. It had to be told explicitly that this is a property assignment,
and more specifically, a sync property (--sync-property username=foo).
This was necessary because theoretically, there might be sync and source
properties with the same name. But that would be confusing and thus was
avoided (and should be in the future).
That leaves the question of distinguishing parameters and the config
name from property assignments. That's easy, anything starting with a
dash is a parameter, anything with an equal sign an assignment. Explicit
--sync-property and --source-property parameters can be used to resolve
ambiguities.
--
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 years, 7 months
Re: [SyncEvolution] [PATCHES] Webdav: in case of 404 when contacting server, assume 401
by Patrick Ohly
On Fr, 2011-06-17 at 09:13 +0100, Salvatore Iovene wrote:
> On Tue, 07 Jun 2011 16:40:07 +0200
> Patrick Ohly <patrick.ohly(a)intel.com> wrote:
>
> > Translating the 404 error into 401 is too aggressive. It should only
> > be done if the path for which the error was triggered really was the
> > one where %u was substituted.
>
> do you mean any path that includes the username or just the path that
> we access for the first time AND it includes the username?
"first time" and "includes the username". Once we have identified
correct credentials and the corresponding path, reporting 401 would just
be confusing.
IMHO, of course. Google itself even has it in their help pages somewhere
that credentials may have to be entered multiple times although they
were correct.
--
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 years, 7 months
[SyncEvolution] [REVIEW REQUEST] Use MNotification in syncevo-dbus-server
by Salvatore Iovene
Hi,
I have refactored the use of notifications in syncevo-dbus-server,
making it generic through the use of design patterns such as factories
and backends.
There is a NotificationManagerFactory object that creates a
NotificationManager that uses the right backend (MLite, libnotify, or a
dummy no-op backend) and syncevo-dbus-server.cpp is now agnostic to
what's happening behind the scene.
This architecture might seem overly complicated, but it would be really
easy to expand in the future, should the need arise.
Here's some stats, and please check the patches attached. You can also
find the code in the "notifications" branches in syncevolution's
gitorious repository.
$ git diff master --stat
configure-pre.in | 18 +++-
src/Makefile-gen.am | 8 +-
src/NotificationBackendBase.h | 42 +++++++
src/NotificationBackendLibnotify.cpp | 126 +++++++++++++++++++++
src/NotificationBackendLibnotify.h | 76 +++++++++++++
src/NotificationBackendMLite.cpp | 65 +++++++++++
src/NotificationBackendMLite.h | 44 +++++++
src/NotificationBackendNoop.cpp | 44 +++++++
src/NotificationBackendNoop.h | 44 +++++++
src/NotificationManager.cpp | 52 +++++++++
src/NotificationManager.h | 75 +++++++++++++
src/NotificationManagerBase.h | 43 +++++++
src/NotificationManagerFactory.cpp | 57 ++++++++++
src/NotificationManagerFactory.h | 43 +++++++
src/dbus/interfaces/syncevo-server-full.xml | 8 ++
src/syncevo-dbus-server.cpp | 161 ++++++---------------------
16 files changed, 773 insertions(+), 133 deletions(-)
$ git log --pretty=oneline 9a849f6588052ef093aaed038bddc23a10bf952b..HEAD
b16777e603daa259d67332a2f0f401927527d296 syncevo-dbus-server: use a "factory" to create the appropriate NotificationManager.
b7bcad6c01c9364a39b5b5730b02fc66dcf0d207 syncevo-dbus-server: update MNotification parameters to correct ones.
507e5a308b288faf400bf0f09bfd4143d7fbad43 syncevo-dbus-server: use #defines for the dbus parameters.
fe2e6d17335aa8884f0252784c8148202737b503 syncevo-dbus-server: initial implementation of mlite backend.
94abeee4f52c278ef3cdadf2e8e1964d8169c5dc syncevo-dbus-server: added inclusion for Noop notification backend.
011c750c6c91c735fd2f0bfa52d141f884af92bc syncevo-dbus-server: semi-working stub for mlite notifications.
9978e870f532cb0787959c32fa4ae8a9e1ffcc17 syncevo-dbus-server: notifications system made more generic.
Regards,
Salvatore.
--
Salvatore Iovene <salvatore.iovene(a)linux.intel.com>
Linux Software Engineer
Intel Open Source Technology Center, Finland
Tel.: +358504804026
9 years, 7 months
