[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.
10 years, 7 months
[SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful)
by Patrick Ohly
[moving to SyncEvolution list]
On Di, 2011-01-04 at 10:30 -0800, Emanoil Kotsev wrote:
> Hi,
>
> I need to catch up with the thread, but for now I want to answer to this here
>
> --- On Mon, 1/3/11, Patrick Ohly <patrick.ohly(a)gmx.de> wrote:
>
> > have). GPE is one example. Akonadi another. I already wrote
> > a prototype
> > backend for Akonadi, but now need a developer who is
> > motivated to finish
> > and maintain it.
I should have mentioned that Dinesh is working on it; I just haven't
seen the result yet and don't know whether he wants to stay around once
it is included (maintenance!).
> If you give me access to the code I could fix it, as I am highly
> motivated to have KDE4 sincable in near future (until someone fixes
> the rest of opensync).
Dinesh, is there a chance that Emanoil helps with the SyncEvolution
Akonadi backend? I can imagine that the work can be split up easily (for
example, you doing the KDE integration (HTTP, KWallet, GUI), while
Emanoil does the actual sync backend), but you know best what the
current status is.
Emanoil, attached Dinesh's last email on the subject. None of his work
is in the main SyncEvolution. We did one code review a while back and
determined that further work was needed to make it ready.
I'd be very interested to get as many suitable patches integrated now.
1.2 (= master) is still in an experimental phase, so modifying core code
is okay. The Akonadi backend can be modified at any time, it is just a
question of when it is ready for users.
--
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 years, 9 months
[SyncEvolution] Trying to follow the http-server-howto
by Carl Erberg
Hi all,
After having a look at funambol I decided not to use it (no debian
packages, only all in one blob, that opens million ports).
So now my next approach to getting my E71 to sync with several
desktops/notebooks is the syncevolution http server. I tried to follow
the description at
http://syncevolution.org/development/http-server-howto
Unfortunately it is not very precise so maybe someone can help me with
the following points:
I successfully worked through the server setup until step 7, adjusted
the commands a little as I installed in /opt. I also added an SSL
tunnel to the server via socat. I can do a connect to the http server
and it works (it answers).
Now at step 8 I was not sure which client is meant "the client". I
used one Desktop with a plain syncevolution install together with
sync-ui for a first try, is that correct?
Now the syncevolution client dies if I give it an https:// URL with a
self-signed certificate. Has anyone some hints on how to deal with
this?
Without being able to connect via SSL I was not able to continue.
Step 9 lets me wonder: Which output should I search? The client? The server?
Thanks for your help!
Regards
Carl
10 years, 11 months
[SyncEvolution] remove debian/ dir from source
by toabctl
Hi,
i want to ask if it's possible to remove the debian-directory from the git
source.
Reasons:
- the debian/control files is outdated. packages like libedataserver-dev
does not exist anymore in debian squeeze
- david bremner works on a much better packed version of syncevolution (see
git://git.debian.org/collab-maint/syncevolution.git )
- i try to set up a daily build on launchpad for syncevolution but that does
not work (or i don't know how) with a already existing debian-dir
Any reasons why the debian-dir should exist?
Cheers,
Tom
10 years, 11 months
[SyncEvolution] SyncEvolution 1.2: downgrade not possible, introduce config versioning
by Patrick Ohly
Hello!
Since the beginning it was always possible to switch back and forth
between SyncEvolution releases. When backwards-incompatible on-disk
changes were necessary, the user had to explicitly asked for them with
the --migrate option (needed only once so far, to get the config layout
change).
For 1.2, this will no longer be possible, because libsynthesis changes
its on-disk format ("binfile") in a backwards-incompatible way (can read
old format, but old version cannot read new one).
On that occasion I also want to make several other changes which will
prevent going back:
1. split "type" into independent options, to solve
http://bugs.meego.com/show_bug.cgi?id=1023
2. rename "evolutionsource" to "database", "evolutionuser/password"
to "backendusername/password", with the old names accepted as
alias, but not being written to disk
Here's how I intend to handle the transition:
* Pre-releases of 1.2 will refuse to do anything with a config
unless its complete context gets migrated with "--migrate
@<context>"; this will also migrate all configs inside that
context. The error message will explain this. Migration happens
by renaming ~/.config/syncevolution/default to
~/.config/syncevolution/default.old and then recreating
~/.config/syncevolution/default with the new content. So it will
be possible to go back, but only with slow or refresh syncs.
* The final 1.2 will do the migration automatically, because most
users (in particular those relying on a GUI) will have problems
with the pre-release error messages.
* I'll introduce .version files in ~/.config/syncevolution,
~/.config/syncevolution/* and ~/.config/syncevolution/*/peers/*.
The content are two numbers, one specifying the oldest format
definition that the directory is compatible with, the other
specifying the current definition. Each SyncEvolution binary
needs to check that it's current definition falls into that
range, otherwise it is too old and cannot use the config. Using
two numbers has the advantage that backwards-compatible
extensions are possible.
The problem will be that SyncEvolution 1.1.x does not yet check that
version. After migrating the configs, it'll fail to find the "type"
property. I hope not too many users will fall into that trap.
Any comments? Implementation will commence soonish.
--
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 years, 11 months
[SyncEvolution] sync-ui: Add new service doesn't work
by Frederik Elwert
Hi!
On the German ubuntuusers.de forum, someone just pointed out that the
“add new service” button in sync-ui doesn’t work. Means, clicking it
just has no effect. Thus, it is not possible to configure services that
are not in the list of consumer ready templates (eGroupWare in this
case).
Is this already known, or did something break in the last releases?
Regards,
Frederik
10 years, 11 months
[SyncEvolution] VersionSync, Support for PIM versioning
by irene scionti
Hi, I'm Irene Scionti, my colleague Alessio Di Pietro and I have delevoped
VersionSync, a support for PIM versioning for syncevolution. If you go to
http://code.google.com/p/versionsync/ you can find the installation
package, that contains all the sources and an installation script (on Ubuntu it
also installs all the dependences).
Briefly our project consists of two parts: the VersionSync engine and the User
Interface for restoring pim data. The first one has a script that, when the
start command is launched, sets a watch on Pim data files, for monitoring all
their changes. When something happens a part of our program runs, performing
actions such as: if a new entry is added, it indexes and puts it under version
control, or, if it is already present, it updates its state and creates a new
version.
The User Interface consists of a web interface for searching and restoring pim
data. When a research is done, the result is shown by a table with all the
entries and their revisions which satisfy the research criteria given. Each
record of the table has a button for restoring the entry.
Thank you for your attention, we hope that you visit our page on google code
soon. Enjoy our project and give us some advices and helps!
Best Regards,
Irene Scionti
http://code.google.com/p/versionsync/
10 years, 11 months
Re: [SyncEvolution] NetworkManager
by Patrick Ohly
On Mo, 2011-01-31 at 05:23 +0000, Ville Nummela wrote:
> I added support for NetworkManager to syncevo-dbus-server. There are two
> commits for this on my clone of the syncevolution repository
> (http://meego.gitorious.org/~vige/meego-middleware/viges-syncevolution).
> The commit ids 02cae38c and 8e3d7b98 are the relevant ones for this.
Looks reasonable, works as promised :-) Thanks a lot. I'll cherry-pick
those for "master". I like to keep a linear history on the master
branch, that's why I don't just merge branches. We debated the pros and
cons a while back here, that's what we settled on.
> There are also my changes for the sync-ui, which add the possibility to
> change the sync interval from the gui.
That one is a bit more problematic. Do we really want to expose the user
to the internal text format? Some kind of slider would be better IMHO.
The empty string field also doesn't tell the user that there is already
a default set, so it looks like he has to choose something, without any
guidance. The original issue wasn't so much about "let users choose an
interval" but "provide feedback on how auto sync works"; following that
logic, showing the default would be more important then letting the user
override it.
The sync UI doesn't have a way to determine the built-in default (30m),
so we would have to duplicate that information - not nice, but the best
that can be done at the moment without extending the D-Bus API. See
http://bugs.meego.com/show_bug.cgi?id=535
I also had a more practical problems: I typed "10". After that, adding
any additional character causes the field to loose focus. I also see
that the UI does a SetConfig() call with these preliminary values.
--
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 years, 11 months
Re: [SyncEvolution] NetworkManager
by Patrick Ohly
On Mo, 2011-01-31 at 10:49 +0000, Ville Nummela wrote:
> On Mon, 2011-01-31 at 11:28 +0100, Patrick Ohly wrote:
> > On Mo, 2011-01-31 at 05:23 +0000, Ville Nummela wrote:
> > > There are also my changes for the sync-ui, which add the possibility to
> > > change the sync interval from the gui.
> > That one is a bit more problematic. Do we really want to expose the user
> > to the internal text format? Some kind of slider would be better IMHO.
> > The empty string field also doesn't tell the user that there is already
> > a default set, so it looks like he has to choose something, without any
> > guidance. The original issue wasn't so much about "let users choose an
> > interval" but "provide feedback on how auto sync works"; following that
> > logic, showing the default would be more important then letting the user
> > override it.
>
> I understand your points. My changes were just something I did for
> myself, as I don't want to edit the config files every time I change the
> interval for testing purposes. I'm not an usability expert, so creating
> good UIs is difficult for me.
Same with me.
> I someone tells me exactly what the UI
> should do, I can probably code it.
I can see whether our designers have an idea. I wouldn't hold my breath
for too long, though, it might take a while.
--
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 years, 11 months
[SyncEvolution] some projects related to syncevolution
by Giancarlo
Dear all,
there are a couple of projects related to syncevolution which are being recently
developed.
The guys who are taking care of the projects are brilliant but a little shy and
did not advertise their work until now, so I decided to push them a little bit.
The first project deals with exploiting syncevolution to sync a number of pc's
and cell phones in a seamless and usable way. In other words it is aimed at
efficiently and easily using syncevolution server.
http://code.google.com/p/pim-synchronization/
Patrick already answered some questions from the developers of the project.
The second project deals with adding versioning capabilities to synchronization
engines for both pc and phones. It is very interesting as it uses svn and other
packages to produce an easy to use and efficient server:
http://code.google.com/p/versionsync/
Best regards
Giancarlo
10 years, 11 months
