[Bug 6147] Can't sync with Google Calendar
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=6147
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |congwu.chen(a)intel.com
--- Comment #4 from Chen Congwu <congwu.chen(a)intel.com> 2009-09-16 17:58:53 ---
(In reply to comment #3)
goosync is a third party service provider provides syncml interface converter
for google calendar. But can we trust this? It is far from official. PIM data
is sensitive.
> (In reply to comment #2)
> > I've found a service called goosync (www.goosync.com) which can handle calendar
> > entrys etc. But can't get it to work with SyncEvolution yet...
>
> Not sure about goosync. If it offers a SyncML interface and it doesn't work
> with SyncEvolution, please file an enhancement request.
>
> ScheduleWorld (www.scheduleworld.com) can synchronize calendars with
> SyncEvolution via SyncML and in the background synchronize that with Google.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years
[Bug 6147] Can't sync with Google Calendar
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=6147
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from pohly <patrick.ohly(a)intel.com> 2009-09-16 07:49:35 ---
Google doesn't support calendar sync via SyncML, so in the near term future
there's nothing we can do about this except making this more obvious in the
GUI. Sorry!
That the GUI allows to enable it is (kind of) tracked as #5871, so marking this
as duplicate.
*** This bug has been marked as a duplicate of bug 5871 ***
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years
[Bug 5061] packaging for Fedora 11
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=5061
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #8 from pohly <patrick.ohly(a)intel.com> 2009-09-16 01:23:24 ---
I consider this resolved. Please open a new issue if an updated libtool is
strongly desired in release tar balls.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years
[Bug 3427] poor usability with network interruption: resend messages
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=3427
--- Comment #24 from pohly <patrick.ohly(a)intel.com> 2009-09-16 01:13:54 ---
(In reply to comment #23)
> > Last week on the train I noticed one problem with the implementation: when the
> > network is down completely, starting a sync via the command line reported that
> > the initial message was sent three times. It did that quickly without any
> > apparent delay between the attempts. However, I cannot reproduce that anymore.
> >
> Yes, when it was caused by network failure, it just resends immediately. Now
> add a intentional sleep (this is still responsive for CTRL+C events).
I have merged the code to get the adaption to the modified libsynthesis engine
included and tested, but this timeout code needs more work.
First, calling sleep() for a long duration prevents the syncevo-dbus-server
from responding to D-Bus messages. Please introduce a
EvolutionSyncClient::sleep() method which calls sleep() by default and in the
DBusSyncClient runs the main loop while waiting. EvolutionSyncClient::sleep()
should not return prematurely unless the time out expires or CTRL-C was
pressed. sleep() could return early when some other signal is received
(unlikely, but not impossible).
Second, the total duration for which we try to resend messages is not
deterministic. This already was a problem before, I just didn't quite realize
it.
We always wait for the fixed delay between message sends, but we don't know how
long the transport was trying to send. It might return quickly (as you said in
a comment), but it might also try for a considerable amount of time before
giving up, for example in DNS lookups. I think I have seen both happening in
practice.
I therefore suggest to change the definition of our configuration variables and
the implementation:
ResendTimeout => RetryDuration (5min)
"The total amount of time in which the client\n"
"tries to get a response from the server.\n"
"During this time, the client will resend messages\n"
"in regular intervals (RetryInterval) if no response\n"
"is received or the message couldn't be delivered due\n"
"to transport problems. When this time is exceeded\n"
"without a response, the synchronization aborts without\n"
"sending further messages to the server."
ResendRetries => RetryInterval (1min)
"The time between the start of message sending and\n"
"the start of the retransmission. If the interval has\n"
"has already passed when a message send returns, the\n"
"message is resent immediately.\n"
The implementation must be changed so that it records the start of a message
send or retransmit and then calculates the sleep duration accordingly.
With this definition, it is more deterministic how long the client will try to
send (plus a possible timeout in the last resend). Previously, the users had to
do some (admittedly simple) math to calculate the duration and there was quite
a bit of uncertainty (RetryCount * timeout).
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years
[Bug 3604] command line: use keyring
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=3604
--- Comment #29 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-09-16 00:28:07 ---
> Looks to me like we have to pass this piece of information into the
> askPassword/savePassword() methods as additional context information.
Yes, we have to.
> > So I'd like to use
> > serverTemplates to find server name with the key "WebURL" for serverTemplates
> > contains pairs of "server name" and "WebURL".
>
> No, don't. Currently we can have two server configurations "scheduleworld_1"
> and "scheduleworld_2" with different calendars (and thus different backend
> passwords) configured for "calendar".
> If I understand correctly what you
> propose, you would look for a server configuration which has the same WebURL as
> the one you currently deal with, so you could end up with "scheduleworld_1"
> when working with "scheduleworld_2" (or vice versa).
Yes, I understand. But if I have 2 server configs for one syncML server(maybe 2
accounts), one is 'Fun1' and another is 'Fun2'. Actually they use the same
calendar backend. Then If we use 'Fun1' and 'Fun2' instead of 'Funambol', then
these 2 passwords are duplicated in the keyring.
But anyway, it is feasible. I'll implement it.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are watching someone on the CC list of the bug.
13 years
[Bug 3604] command line: use keyring
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=3604
--- Comment #28 from pohly <patrick.ohly(a)intel.com> 2009-09-16 00:12:52 ---
(In reply to comment #27)
> > There's still a hard-coded list of passwords inside
> > EvolutionSyncConfig::preFlush(). Passwords added dynamically by backends
> > therefore won't be stored in the keyring.
> >
> > Here's how this can be solved:
> > * add a virtual checkPassword(ConfigUserInterface &ui,
> > ConfigNode &globalConfigNode,
> > const boost::shared_ptr<FilterConfigNode>
> > &sourceConfigNode = boost::shared_ptr<FilterConfigNode>())
> > to ConfigProperty, with an empty implementation. Similar for savePassword().
> > * Override these methods in the actual PasswordProperty implementations.
> > * iterate over *all* sync and source properties and invoke the virtual
> > methods
> "checkPassword" is used for 'retrieving password' so I add 'savePassword' in
> the ConfigProperty class to save password.The default impl is empty. Current
> password impl classes have override them.
>
> Since ConfigProperties are registered in ConfigPropertyRegistry, pseudocode is:
> void preflush(ConfigUserInterface &ui) {
> for each ConfigProperty in Sync Registry
> ConfigProperty->savePassword(ui, globalConfigNode);
>
> for each sourceConfigNode in sourcenodes
> for each ConfigProperty in Source Registry
> ConfigProperty->savePassword(ui, globalConfigNode, sourceConfigNode)
> }
> Reasonable?
Yes, that's what I was thinking of.
> > You didn't comment on that and now used "server URL" as part of the "object"
> > key, leading to "ns5.scheduleworld.com/funambol/ds ical20 backend". The backend
> > password is not related to the server URL, which might even be empty for other
> > transports. I still think the server configuration name would be a better
> > choice; later we should switch to the "source set configuration name".
> Yes, I didn't see this story until today. I use "server URL" instead of 'server
> name' for currently there is no place to store "server name" in the
> EvolutionSyncConfig and so is global config file.
Looks to me like we have to pass this piece of information into the
askPassword/savePassword() methods as additional context information.
> So I'd like to use
> serverTemplates to find server name with the key "WebURL" for serverTemplates
> contains pairs of "server name" and "WebURL".
No, don't. Currently we can have two server configurations "scheduleworld_1"
and "scheduleworld_2" with different calendars (and thus different backend
passwords) configured for "calendar". If I understand correctly what you
propose, you would look for a server configuration which has the same WebURL as
the one you currently deal with, so you could end up with "scheduleworld_1"
when working with "scheduleworld_2" (or vice versa).
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are watching someone on the CC list of the bug.
13 years