6:05 a.m.
Hello, Patrick, community.
1st of all I wanted to convince you that I appreciate SyncEvolution.
This is a great piece of software, and what's most important: it works.
But now I wanted to raise one question: do you intend to refactor the
design of it?
I mean I just read out the
https://syncevolution.org/documentation/syncevolution-usage#terminology
and it is statistically:
Lines 29
Words 837
Symbols 5155
This means tens of concept terms! I mean: it's not easy to understand
and surely takes noticeable effort to get used to. This is especially
wonderful knowing that opensync was already there, which had _much_
simpler design (while I understand that it may not cover all the needs
that syncevo deal with).
I don't mean to criticize but just ask: do you plan to do something
with it, say, for the next major release?
Best regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
home: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
7:13 a.m.
On Fri, 2012-09-07 at 12:05 +0600, Ildar Mulyukov wrote:
Hello, Patrick, community.
1st of all I wanted to convince you that I appreciate SyncEvolution.
This is a great piece of software, and what's most important: it works.
But now I wanted to raise one question: do you intend to refactor the
design of it?
If you have an idea for making it simpler, then I am all ears. I don't
have such an idea (at least not without removing functionality) and thus
no plans to change anything :-/
I guess what could be done is to design another frontend with less
features. Then the implementation can hide details by making choices for
the user. The GTK UI is such a simpler frontend.
I mean I just read out the
https://syncevolution.org/documentation/syncevolution-usage#terminology
and it is statistically:
Lines 29
Words 837
Symbols 5155
This means tens of concept terms! I mean: it's not easy to understand
and surely takes noticeable effort to get used to. This is especially
wonderful knowing that opensync was already there, which had _much_
simpler design
And did that design work? How large was the terminology section of their
documentation, and was it complete?
What I am aiming at here is that besides "SyncEvolution is too complex"
there's also the explanations that "it is more complex because it has to
be" (as you said) and "it has better documentation".
I haven't used OpenSync in a long time because there hasn't been a
stable, supported release for ages. But I strongly suspect that if it
looks simpler today, then it is because it hides the complexity behind a
simple facade without a fully functional implementation behind it. We
can talk again when an OpenSync release shows that the simpler design
really can be implemented.
--
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:02 a.m.
Dear Patrick,
please, don't be offended by my questions!
On 07.09.2012 13:13:33, Patrick Ohly wrote:
If you have an idea for making it simpler, then I am all ears. I
don't
have such an idea (at least not without removing functionality) and
thus
no plans to change anything :-/
I'm still learning syncevo, so no perfect understanding.
I guess what could be done is to design another frontend with less
features. Then the implementation can hide details by making choices
for
the user. The GTK UI is such a simpler frontend.
I know.
> This means tens of concept terms! I mean: it's not easy to
understand
> and surely takes noticeable effort to get used to. This is
especially
> wonderful knowing that opensync was already there, which had _much_
> simpler design
And did that design work? How large was the terminology section of
their
documentation, and was it complete?
:)
What I am aiming at here is that besides "SyncEvolution is too
complex"
there's also the explanations that "it is more complex because it has
to
be" (as you said) and "it has better documentation".
No doubt in that.
I haven't used OpenSync in a long time because there hasn't
been a
stable, supported release for ages. But I strongly suspect that if it
looks simpler today, then it is because it hides the complexity
behind a
simple facade without a fully functional implementation behind it. We
can talk again when an OpenSync release shows that the simpler design
really can be implemented.
That's why it's no use talking about OpenSync here.
I just wanted to: formulate the problem (with understanding), ask about
plans and propose a thing to think about, maybe (about OpenSync
approach).
One word I used initially is "to refactor". I used it with meaning "to
change something internal without losing functionality".
I'd prefer to get some more experience before continuing this
discussion. Just wanted to ask what you and others think.
Thanks for the answer. Regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
home: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
9:39 a.m.
On Fri, 2012-09-07 at 15:02 +0600, Ildar Mulyukov wrote:
Dear Patrick,
please, don't be offended by my questions!
No worries, your questions are perfectly fine and justified.
SyncEvolution *is* complex - but so is syncing. Besides, I have a thick
skin ;-}
I just wanted to: formulate the problem (with understanding), ask
about
plans and propose a thing to think about, maybe (about OpenSync
approach).
Fair enough.
I'd prefer to get some more experience before continuing this
discussion. Just wanted to ask what you and others think.
Okay. I look forward to getting more feedback (and ideally, a proposal)
in the future. Someone who is new to the project will definitely have a
better chance to see things with fresh eyes and be able to think outside
of the box.
--
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.
6:30 a.m.
On 07.09.2012 15:39:05, Patrick Ohly wrote:
On Fri, 2012-09-07 at 15:02 +0600, Ildar Mulyukov wrote:
> I'd prefer to get some more experience before continuing this
> discussion. Just wanted to ask what you and others think.
Okay. I look forward to getting more feedback (and ideally, a
proposal)
in the future. Someone who is new to the project will definitely have
a
better chance to see things with fresh eyes and be able to think
outside
of the box.
Hi,
at last I feel confident enough to move on:
https://syncevolution.org/wiki/architecture-overview
Please fix it to the TRUE state then I make a proposal :)
Regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
7:32 a.m.
On Wed, 2012-09-19 at 12:30 +0600, Ildar Mulyukov wrote:
Hi,
at last I feel confident enough to move on:
https://syncevolution.org/wiki/architecture-overview
Please fix it to the TRUE state then I make a proposal :)
That looks like a rewrite of the terminology section in the README.rst,
right? It's a bit briefer, albeit at the cost of not defining some
terms. I'm not sure whether it is an improvement - that's something that
users need to decide.
I don't agree with your definition of "Database" (= "A Database is a
type of data which is in a Source."). You list "addressbook",
"calendar", etc. as examples. for databases. Those are not databases,
they merely refer to one.
A more accurate definition is that a database is a collection of items
of a certain type (an address book database contains contacts).
"addressbook" is the name of a source which is defined as part of some
of the configuration templates. In addition, "addressbook" is also used
as alias for backends which provide access to databases which contain
contacts.
--
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:56 a.m.
Hi, Patrick,
On 19.09.2012 13:32:59, Patrick Ohly wrote:
On Wed, 2012-09-19 at 12:30 +0600, Ildar Mulyukov wrote:
> Hi,
> at last I feel confident enough to move on:
> https://syncevolution.org/wiki/architecture-overview
> Please fix it to the TRUE state then I make a proposal :)
That looks like a rewrite of the terminology section in the
README.rst, right?
No,
this was written from scratch, I just took one phrase from
https://syncevolution.org/documentation/syncevolution-usage (which is
README.rst, right?)
It's a bit briefer, albeit at the cost of not defining some
terms. I'm not sure whether it is an improvement - that's something
that
users need to decide.
Yes, sure.
I doubt that this would be useful for experienced SyncEvo users, but
this is my newbie-point-of-view-and-understanding, hence may be good
for nubz like me.
Some terms indeed disappeared as I treated them non-important for
noobz. This page is by no means an Ultimate Reference, so I though I
could do that.
I don't agree with your definition of "Database" (=
"A Database is a
type of data which is in a Source."). You list "addressbook",
"calendar", etc. as examples. for databases. Those are not databases,
they merely refer to one.
A more accurate definition is that a database is a collection of items
of a certain type (an address book database contains contacts).
"addressbook" is the name of a source which is defined as part of some
of the configuration templates. In addition, "addressbook" is also
used
as alias for backends which provide access to databases which contain
contacts.
You are right. I should get rid of it too. Just leaving uri= setting
explanation.
One main thing about this page is to not be misleading. So 1st I want
is to get the page to an appropriate state. Please help me with that.
Regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
10:25 a.m.
On Wed, 2012-09-19 at 15:56 +0600, Ildar Mulyukov wrote:
Hi, Patrick,
On 19.09.2012 13:32:59, Patrick Ohly wrote:
> On Wed, 2012-09-19 at 12:30 +0600, Ildar Mulyukov wrote:
> > Hi,
> > at last I feel confident enough to move on:
> > https://syncevolution.org/wiki/architecture-overview
> > Please fix it to the TRUE state then I make a proposal :)
>
> That looks like a rewrite of the terminology section in the
> README.rst, right?
No,
this was written from scratch, I just took one phrase from
https://syncevolution.org/documentation/syncevolution-usage (which is
README.rst, right?)
Right.
Your current understanding as documented on that page is correct.
Writing it up is definitely a good exercise, I'm just not sure what to
do with the page now. To make the relationship with the "official"
documentation clear I've added a link to the terminology section.
--
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:31 a.m.
On 19.09.2012 16:25:14, Patrick Ohly wrote:
On Wed, 2012-09-19 at 15:56 +0600, Ildar Mulyukov wrote:
> this was written from scratch, I just took one phrase from
> https://syncevolution.org/documentation/syncevolution-usage (which
is
> README.rst, right?)
Right.
Your current understanding as documented on that page is correct.
Writing it up is definitely a good exercise, I'm just not sure what to
do with the page now. To make the relationship with the "official"
documentation clear I've added a link to the terminology section.
That's fair. Thank you.
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
5:17 a.m.
New subject: [SyncEvolution] consept is too complicated: proposals (1)
As promised, my 1st proposal (in two parts).
1. As Patrick confirms, "Contexts are profiles independent of each
other".
a. the "Context" word is quite inconvenient and ...
"context-specific", it isn't clear enough for understanding. Maybe it's
worth to use the "profile" word for that, leaving "context" as a
legacy
term meaning a _profile_.
b. For syncevolution cmdline tool: Move it from the @<context> part
to a --profile <profile name>. Again, for clear understanding.
What do ya think?
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
6:52 a.m.
New subject: [SyncEvolution] consept is too complicated: proposals (1)
On Thu, 2012-09-20 at 11:17 +0600, Ildar Mulyukov wrote:
As promised, my 1st proposal (in two parts).
1. As Patrick confirms, "Contexts are profiles independent of each
other".
But I didn't use the word profile, did I?
a. the "Context" word is quite inconvenient and ...
"context-specific", it isn't clear enough for understanding. Maybe it's
worth to use the "profile" word for that, leaving "context" as a
legacy
term meaning a _profile_.
For me, "profile" sounds more like a flat, predefined or editable set of
options. A quick Google search for "configuration profile" brings up for
example "Configuration Profiles" in Wireshark:
http://www.wireshark.org/docs/wsug_html_chunked/ChCustConfigProfilesSecti...
Or "profile configuration files", .pcf.
http://en.wikipedia.org/wiki/Profile_configuration_file
These "profiles" match with SyncEvolution's "templates", not the
"contexts".
b. For syncevolution cmdline tool: Move it from the
@<context> part
to a --profile <profile name>. Again, for clear understanding.
I agree that changing the command line would be worthwhile. Giving
configuration and sources via positional arguments made it very hard to
check for syntax errors or typos. It's a big change, though, which
renders all existing HOWTOs invalid.
Whether it is worth having a separate --profile (or --context) switch is
open for debate. Would you also change all output which currently uses
the @<context> notation?
What do ya think?
I'd like to hear from more users what they think about this. What I see
primarily are the negative effects (incompatible command line changes,
the work for implementing all this, risk of new bugs), so I'd like to
get some kind of confirmation that it would be worthwhile.
--
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.
8:29 a.m.
New subject: [SyncEvolution] consept is too complicated: proposals (1)
On 20.09.2012 12:52:34, Patrick Ohly wrote:
On Thu, 2012-09-20 at 11:17 +0600, Ildar Mulyukov wrote:
> As promised, my 1st proposal (in two parts).
>
> 1. As Patrick confirms, "Contexts are profiles independent of each
> other".
But I didn't use the word profile, did I?
sure :)
> a. the "Context" word is quite inconvenient and
...
> "context-specific", it isn't clear enough for understanding. Maybe
it's
> worth to use the "profile" word for that, leaving "context" as a
legacy
> term meaning a _profile_.
For me, "profile" sounds more like a flat, predefined or editable set
of
options. A quick Google search for "configuration profile" brings up
for
example "Configuration Profiles" in Wireshark:
http://www.wireshark.org/docs/wsug_html_chunked/ChCustConfigProfilesSecti...
Or "profile configuration files", .pcf.
http://en.wikipedia.org/wiki/Profile_configuration_file
These "profiles" match with SyncEvolution's "templates", not the
"contexts".
Mozilla profiles come to me a lot quicker. Ok, maybe profile is
imperfect here, but it's much more intuitive for this case, IMHO.
But I agree, someone has to come and judge us :)
> b. For syncevolution cmdline tool: Move it from the
@<context>
part
> to a --profile <profile name>. Again, for clear understanding.
I agree that changing the command line would be worthwhile. Giving
configuration and sources via positional arguments made it very hard
to
check for syntax errors or typos. It's a big change, though, which
renders all existing HOWTOs invalid.
Whether it is worth having a separate --profile (or --context) switch
is
open for debate. Would you also change all output which currently uses
the @<context> notation?
Might have a soft move allowing both new and old notation with warning
when a user uses old one. After all, "contexts" aren't used by dumb GUI
users, so mid and expert users can adopt quickly.
Regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
12:45 p.m.
New subject: [SyncEvolution] consept is too complicated: proposals (1)
On 09/20/2012 07:17 AM, Ildar Mulyukov wrote:
As promised, my 1st proposal (in two parts).
1. As Patrick confirms, "Contexts are profiles independent of each other".
a. the "Context" word is quite inconvenient and ...
"context-specific",
it isn't clear enough for understanding. Maybe it's worth to use the
"profile" word for that, leaving "context" as a legacy term meaning
a
_profile_.
I don't like it. It would be too confusing. The way the word "profile"
is used elsewhere, it usually signifies a concept which has absolutely
nothing to do with what SyncEvolution contexts are. Hence, using the
word "profile" here would mean forcing people to unlearn what they think
profile means, and make them think "why do they call this a profile,
when it's not like what I'm used to calling a profile? why didn't they
call it something meaningful and less confusing, like, hmm, contexts?"
A SyncEvolution context is a bit like a directory, a domain, or a
namespace, but *not* like a profile, as far as I'm concerned. I'm quite
unable to think of a SyncEvolution context as a profile, it just doesn't
make sense.
b. For syncevolution cmdline tool: Move it from the @<context>
part to a
--profile <profile name>. Again, for clear understanding.
What do ya think?
I don't like this either. I prefer commandlines to be short. And if
you're able to think of a context as a domain, then the @ notation makes
quite a bit of sense. Like an email address.
2:37 p.m.
New subject: [SyncEvolution] consept is too complicated: proposals (1)
On Thu, 2012-09-20 at 14:45 +0200, Ove Kåven wrote:
> b. For syncevolution cmdline tool: Move it from the
@<context> part
to a
> --profile <profile name>. Again, for clear understanding.
>
> What do ya think?
I don't like this either. I prefer commandlines to be short. And if
you're able to think of a context as a domain, then the @ notation
makes quite a bit of sense. Like an email address.
FWIW, that was also my thinking when introducing contexts and the
notation for them.
Other reasons:
* Consistency between output and command line usage.
* Backward compatibility for the commmand line: tools which
treated a config name as an opaque string continued to work
unchanged.
--
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:23 a.m.
New subject: [SyncEvolution] consept is too complicated: proposals (1)
On 20.09.2012 20:37:58, Patrick Ohly wrote:
On Thu, 2012-09-20 at 14:45 +0200, Ove Kåven wrote:
> I don't like this either. I prefer commandlines to be short. And if
> you're able to think of a context as a domain, then the @ notation
> makes quite a bit of sense. Like an email address.
FWIW, that was also my thinking when introducing contexts and the
notation for them.
Other reasons:
* Consistency between output and command line usage.
* Backward compatibility for the commmand line: tools which
treated a config name as an opaque string continued to work
unchanged.
"... the testimony of two men is true." (Jn.8:17)
I'm noob and you've much longer experience with it. Anyway, I've got my
quicksheet to look at and get to know what is what :)
Case closed, thank you all.
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
6:05 a.m.
New subject: [SyncEvolution] consept is too complicated: proposals (2)
Proposal #2. Turn peer configuration into just-another-source kind.
(As being quite new to SyncEvo) I don't see a big difference between
"source" and "peer" configurations. At least, the difference isn't
bigger then for example the difference between supported sources
backends. Even more, some of the sources look more like remote peers,
but only with another protocol (CalDAV and ActiveSync come to mind).
Peers are just sources, special in one thing: they are SyncML-servers.
But as SyncEvo can bear this functionality, and this makes peers no
more special: sources can now sync between each other without peers
(using target-config, currently).
Accepting this change would bring us to a simpler picture where every
context has just a set of sources each having:
1. the database/databases property
2. the sync mode, which clearly defines data flow permissions, e.g. rw,
read-only, write-only, none
3. their whitelist and/or blacklist of sources to sync with. E.g. I
want my phone (backend=obex) to sync with the local addressbook
(backend=eds), but not with Google (backend=SyncML-server).
Depending on types of sources to be synced, SyncEvo may decide to use
embedded SyncML-server or source's server capability if backend is
"SyncML-server".
And drop the cryptic target-config.
Just my fantasy, but what do you think?
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
4:07 p.m.
New subject: [SyncEvolution] consept is too complicated: proposals (2)
On Tue, 2012-10-09 at 12:05 +0600, Ildar Mulyukov wrote:
Proposal #2. Turn peer configuration into just-another-source kind.
(As being quite new to SyncEvo) I don't see a big difference between
"source" and "peer" configurations. At least, the difference
isn't
bigger then for example the difference between supported sources
backends. Even more, some of the sources look more like remote peers,
but only with another protocol (CalDAV and ActiveSync come to mind).
Peers are just sources, special in one thing: they are SyncML-servers.
There is another difference: a peer has multiple sources. A source only
has one. You suggest to remove that difference and also the per-peer
properties of a source, right?
How would the user request a sync of all sources configured for a
specific peer ("syncevolution funambol", for example)?
Accepting this change would bring us to a simpler picture where every
context has just a set of sources each having:
1. the database/databases property
2. the sync mode, which clearly defines data flow permissions, e.g. rw,
read-only, write-only, none
3. their whitelist and/or blacklist of sources to sync with. E.g. I
want my phone (backend=obex) to sync with the local addressbook
(backend=eds), but not with Google (backend=SyncML-server).
Where do you put the username/password that is needed to access a peer?
Duplicate it for each source in that peer or configure credentials
separately (similar to
https://bugs.freedesktop.org/show_bug.cgi?id=52917 "shared
credentials")?
Where and how is the connection between two sources specified? Where are
the settings related to that connection (loglevel, data direction)? It
is possible to have sources A, B, C, D connected like this: A<->B,
A<->C, C<->D.
A single value for connection properties in a source will not work,
because A and C both have more than one.
Depending on types of sources to be synced, SyncEvo may decide to use
embedded SyncML-server or source's server capability if backend is
"SyncML-server".
And drop the cryptic target-config.
Just my fantasy, but what do you think?
I think it may be possible to get rid of "target-config" but the
"peer"
concept in general seems necessary and 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.
3:43 p.m.
New subject: [SyncEvolution] consept is too complicated: proposals (2)
On Fri, 2012-10-12 at 18:07 +0200, Patrick Ohly wrote:
On Tue, 2012-10-09 at 12:05 +0600, Ildar Mulyukov wrote:
> Proposal #2. Turn peer configuration into just-another-source kind.
>
> (As being quite new to SyncEvo) I don't see a big difference between
> "source" and "peer" configurations. At least, the difference
isn't
> bigger then for example the difference between supported sources
> backends. Even more, some of the sources look more like remote peers,
> but only with another protocol (CalDAV and ActiveSync come to mind).
>
> Peers are just sources, special in one thing: they are SyncML-servers.
There is another difference: a peer has multiple sources. A source only
has one. You suggest to remove that difference and also the per-peer
properties of a source, right?
How would the user request a sync of all sources configured for a
specific peer ("syncevolution funambol", for example)?
You did get me thinking :-) I still believe that the "peer" concept is
needed. However, its current implementation with one syncURL per peer is
too limited. It does not cover the case where syncing with one logical
peer involves multiple different protocols, for example SyncML + CalDAV.
Google falls into that category. That's why we had to introduce the ugly
"Google Contacts" and "Google Calendar" config templates.
It would be nice to fix this so that a peer defines all pairs of
sources, regardless of the protocol. It should still be possible to find
all pairs using the same protocol. This is relevant for syncing multiple
sources in a single SyncML session. OTOH, I am not sure how important
that optimization still is. It's actually a bit safer to sync one source
after the other, because then a malfunction only affects one source.
More important perhaps is that it must remain easy for the user to
configure the peer ("syncevolution --configure username=foo password=bar
memotoo").
--
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:19 a.m.
New subject: [SyncEvolution] consept is too complicated: proposals (2)
On 15.10.2012 21:43:55, Patrick Ohly wrote:
You did get me thinking :-)
Hi, Patrick,
I am sorry this discussion had no continuation, that's mainly because
it was powered by the first impression.
Aiming to simplify a thing for users, first, it is not always possible.
Some things are quite complicated by their nature (and for SyncEvo it
starts somewhere in SyncML). Then it's probably worth having another
program as a "presentation" which is easier to understand and use which
uses the original program.
(This isn't, again, the finished thought.)
I just wanted to thank you for being open to discussion and calm
answers to stupid questions.
Best regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
3515
days inactive
3581
days old
syncevolution@synevolution.org
18 comments
3 participants
participants (3)
-
Ildar Mulyukov -
Ove Kåven -
Patrick Ohly