[Bug 3633] New: Synchronize meeting series, receive meeting update via email => Evolution unable to apply update?
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=3633
Summary: Synchronize meeting series, receive meeting update via
email => Evolution unable to apply update?
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: ASSIGNED
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
When synchronizing an event the time zone may get modified. This implies a
change in its TZID. This has the following negative effect on meeting series
handling (= recurring event created and updated via email meeting invitations):
1. synchronize meeting series stored in Evolution
2. later received the synchronize events back (for example,
refresh-from-server)
or synchronize into another Evolution instance
3. receive meeting update for an *individual* recurrence which already
was stored as a separate VEVENT before (UID and RECURRENCE-ID set)
4. update cannot be applied by Evolution, nothing happens (says "sent to
calendar", no error, but also no change in the calendar)
This is with Evolution 2.30.x and a local calendar.
It works if:
* the update is for the complete series (no RECURRENCE-ID)
* the update is for a normal recurrence of the series (no separate
VEVENT)
The root cause seems to be the change of the TZID in the RECURRENCE-ID
property.
The problem is: I can no longer reproduce this issue. I definitely had the
problem, which is why I am filing it here, just in case that it occurs again.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 8 months
[Bug 2764] New: Calendar event alarm synchronization between N900 and Goosync
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=2764
Summary: Calendar event alarm synchronization between N900 and
Goosync
Classification: MeeGo Platform
Product: OS Middleware
Version: 1.0
Platform: Handheld
OS/Version: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: meego(a)jjussi.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs
Estimated Hours: 0.0
Hardware Model (on what HW this bug is uncovered):
Nokia N900 PR1.2 + SyncEvolution 0.9.2
Bug detailed descriptions(behavior, impact, etc)
===========================================================
When sync events from Google calendar using Goosync-service. Event alarms don't
come to N900.
When sync events (created at N900) to Google calendar using Goosync-service.
Events do have alarm set in Google calendar, BUT with 0 (zero) minutes "before"
time.
Reproduce Steps(steps,current result, reproduce possibility)
===========================================================
(1) Create two events with 5 minute "before" alarm, one in Google calendar and
one in N900
(2) Run syncevolution with goosync-service to synchronize events
(3) Check result in both places
Expected result:
===========================================================
Both events should appear at both places with alarm set to 5 minutes before
event
Possible root cause:
===========================================================
Because this works with S60 phone using GooSync and phones own synchronization
program, it must be SyncEvolution what makes error when transferring event.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 8 months
[Bug 3558] New: D-Bus: add Server.ConfigChanged signal
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=3558
Summary: D-Bus: add Server.ConfigChanged signal
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
URL: https://bugzilla.redhat.com/show_bug.cgi?id=606647
Architecture: ---
Status: ASSIGNED
Severity: enhancement
Priority: Medium
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
>From [SyncEvolution] Lessons from Genesis development: Enhancement proposals
Problem:
Watching for configuration changes (e.g., for refreshing the
list of servers in the GUI) currently is a bit cumbersome. It
requires watching for SessionChanged, request GetConfigs, and
look if the configs have changed. This is not really a problem,
but it might be more convenient to get notifications about
config changes directly.
Proposed solution:
Introduce a Server.ConfigChanged signal.
<signal name="ConfigChanged">
<doc:doc>
<doc:description>
Configuration added, updated or removed To find out more, request
list of configurations anew.
</doc:description>
</doc:doc>
</signal>
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 9 months
[Bug 3559] New: D-Bus: add Session.GetConfigName() method
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=3559
Summary: D-Bus: add Session.GetConfigName() method
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: ASSIGNED
Severity: enhancement
Priority: Medium
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
>From [SyncEvolution] Lessons from Genesis development: Enhancement proposals
Problem:
GUIs cannot tell for which server a session was started if the
GUI didn’t start the session itself. So for example when Genesis
sees that a sync session ended and displays the results, it
cannot tell (and therefore cannot show to the user) which server
was actually affected. So e.g. notifying about the results of
automated syncs lacks some rather important information.
Proposed Solution:
Introduce a Session.GetServerName() method.
"Server" is a misnomer, it might also be a client configuration. Also need to
adapt the rest of the config.
<method name="GetConfigName">
<doc:doc>
<doc:description>
<doc:para>Get the configuration name of the session.</doc:para>
<doc:para>Every session is associated with a specific
configuration, as requested by the creator of the session. This
call
returns the normalized configuration name. Note that this may be
different
from the name used when creating the configuration, because that
name
is not required to be normalized. Therefore this method may be
useful
both for the creator of the session and other clients which cannot
know the configuration name without calling this method.</doc:para>
</doc:description>
</doc:doc>
<arg type="s" name="config" direction="out">
<doc:doc><doc:summary>peer configuration name</doc:summary></doc:doc>
</arg>
</method>
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 9 months
[Bug 3560] New: D-Bus: suppress notifications on demand
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=3560
Summary: D-Bus: suppress notifications on demand
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: ASSIGNED
Severity: enhancement
Priority: Medium
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
>From [SyncEvolution] Lessons from Genesis development: Enhancement proposals
Problem:
The syncevo-dbus-server handles user notifications itself (e.g.
for automated syncs.) A GUI might want to notify users about
syncs itself. E.g. Genesis shows a spinning status icon, which
makes the sync started/sync ended notifications of
syncevo-dbus-server redundant.
Proposed Solution:
Clients should be able to tell syncevo-dbus-server not to
display sync notifications. I propose a method
Server.InhibitNotification(bool) which could be used to inhibit
notifications when Genesis is started and allow notifications
before it terminates.
Instead of a simple boolean, let's keep the option open to enable and disable
specific notifications. Thus adding a string parameter and two methods:
<method name="DisableNotifications">
<doc:doc>
<doc:description>
Prevents showing of user visible notifications by the
syncevo-dbus-server.
Must be called while the client is attached to the server.
Notifications
will be disabled until the client detaches or calls
UnlockNotifications().
</doc:description>
</doc:doc>
<arg type="s" name="notifications" direction="in">
<doc:doc><doc:summary>
describes the notifications which are to be disabled; currently
ignored by server, pass empty string
</doc:summary></doc:doc>
</arg>
</method>
<method name="EnableNotifications">
<doc:doc>
<doc:description>
Allows showing of user visible notifications again.
</doc:description>
</doc:doc>
<arg type="s" name="notifications" direction="in">
<doc:doc><doc:summary>
describes the notifications which are to be ensabled; currently
ignored by server, pass empty string
</doc:summary></doc:doc>
</arg>
</method>
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 9 months
[Bug 3562] New: D-Bus: sessions for a specific purpose
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=3562
Summary: D-Bus: sessions for a specific purpose
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: ASSIGNED
Severity: enhancement
Priority: Medium
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
>From [SyncEvolution] Lessons from Genesis development: Enhancement proposals
Clients like Genesis would like to know for which purpose a session was
created. If it was for changing the configuration, they can ignore the session.
If it was for sync, then progress and result should be displayed.
This requires changing the StartSession() call and adding a method to Session
to retrieve the information.
<method name="StartSession">
<doc:doc><doc:description>
Start a session. The object is created instantly but will not be
ready for method calls until status changes from "queueing" to "idle".
The Detach() method can be called before that.
</doc:description></doc:doc>
<arg type="s" name="server" direction="in">
<doc:doc><doc:summary>server name</doc:summary></doc:doc>
</arg>
<arg type="o" name="session" direction="out">
<doc:doc><doc:summary>session D-Bus object path</doc:summary></doc:doc>
</arg>
</method>
<method name="GetFlags">
<doc:doc>
<doc:description>
Get the session flags set with Server.StartSessionWithFlags().
</doc:description>
</doc:doc>
<arg type="a{s}" name="flags" direction="out">
<doc:doc><doc:summary>session flags</doc:summary></doc:doc>
</arg>
</method>
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 9 months
[Bug 3563] New: D-Bus: self description of features
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=3563
Summary: D-Bus: self description of features
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: ASSIGNED
Severity: enhancement
Priority: Medium
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Blocks: 3558,3559,3560,3562
Estimated Hours: 0.0
>From [SyncEvolution] Lessons from Genesis development: Enhancement proposals
We are about to extend the D-Bus API. Clients need some way of determining
whether the new features are available. A strict numbering of the API is
inflexible, so let's use "capability" strings instead. Also add flexible
version querying, for debugging.
<method name="GetCapabilities">
<doc:doc>
<doc:description>
<doc:para>
Describes which features are implemented by the server. If the
method itself
is unavailable, then the features correspond to SyncEvolution 1.0.
The following
capabilities are currently defined:
<doc:list>
<doc:item><doc:term>ConfigChanged</doc:term><doc:definition>Server.ConfigChange
signal available; if not, reread config after each
session</doc:definition></doc:item>
<doc:item><doc:term>GetConfigName</doc:term><doc:definition>Session.GetConfigName()
implemented</doc:definition></doc:item>
<doc:item><doc:term>Notifications</doc:term><doc:definition>Server.DisableNotifications()
and Server.EnableNotifications() implemented</doc:definition></doc:item>
<doc:item><doc:term>Version</doc:term><doc:definition>Server.GetVersion()
implemented; note that this is not meant to be used to determine supported
features</doc:definition></doc:item>
<doc:item><doc:term>SessionFlags</doc:term><doc:definition>Server.StartSessionWithFlags()
and Session.GetFlags() are implemented</doc:definition></doc:item>
</doc:list>
</doc:para>
</doc:description>
</doc:doc>
<arg type="a{s}" name="capabilities" direction="out">
<doc:doc><doc:summary>
set of supported capabilities
</doc:summary></doc:doc>
</arg>
</method>
<method name="GetVersions">
<doc:doc>
<doc:description>
<doc:para>
Returns information about server side implementations.
</doc:para>
</doc:description>
</doc:doc>
<arg type="a{ss}" name="info" direction="out">
<doc:doc><doc:summary>
"version" - main SyncEvolution release name (usually a number,
sometimes also a beta or alpha suffix),
"system" - some plain text information about system libraries,
"backends" - available backend libraries
</doc:summary></doc:doc>
</arg>
</method>
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 9 months
[Bug 3557] New: add --enable-gnome-keyring
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=3557
Summary: add --enable-gnome-keyring
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
URL: https://bugzilla.redhat.com/show_bug.cgi?id=606647
Architecture: ---
Status: ASSIGNED
Severity: enhancement
Priority: Medium
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
Using the GNOME keyring should be optional. Right now it is always on when
found.
--enable-gnome-keyring: fail if not available
--disable-gnome-keyring: disable, even if found
unset: use if found
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 9 months
[Bug 1354] New: EDS: protect against concurrent editing + revision handling
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=1354
Summary: EDS: protect against concurrent editing + revision
handling
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: ASSIGNED
Severity: normal
Priority: High
Component: SyncEvolution
AssignedTo: ross(a)linux.intel.com
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
This is from http://bugzilla.moblin.org/show_bug.cgi?id=3479
Description From pohly 2009-06-12 09:21:04 PST (-) [reply]
If a user edits items while a synchronization is running, then all kinds of
"interesting" things can happen: change is overwritten by server change
(definitely!), change is made locally but never sent to server (not so sure),
...
Part of the problem is that the EDS API is prone to race conditions. This needs
to be fixed first, as discussed with the EDS developers:
http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html
Since that discussion I have implemented automatic restore from backup, which
has
changed my view on the necessary APIs a bit: it would be nice to store
items with a specific REV or LAST-MODIFIED if the libebook/libecal user
knows what he is doing. Not bumping these fields when restoring an items
has the advantage that other clients which were in sync with the
restored data don't see any unnecessary changes.
The other part of the problem is getting a set of item ID + revision string
(REV for contacts, LAST-MODIFIED for event/tasks) in an atomic way. I'm not
sure whether the current methods are really atomic. But worse, they are also
much slower than they could be because we have to transmit the whole content of
the database via D-Bus just to extract the much smaller set of required
information.
Ross wanted to work on a call to return pairs of UID+REV for libebook. I don't
think he got very far with that, though. I think this is a fairly import
optimization.
------- Comment #1 From Chen Congwu 2009-08-06 01:16:53 PST (-) [reply] -------
I will look at it.
------- Comment #2 From Chen Congwu 2009-08-09 22:22:42 PST (-) [reply] -------
I have several questions regarding the api implementation.
Do we need to impl this concurrent feature for all backends? (groupwise,
google, exchange, etc.)
When is eds-dbus port ready? Do we need work on this feature on both bonobo and
dbus? If so, which one has more priority?
[1] http://mail.gnome.org/archives/evolution-hackers/2009-August/msg00004.html
(In reply to comment #0)
> If a user edits items while a synchronization is running, then all kinds of
> "interesting" things can happen: change is overwritten by server change
> (definitely!), change is made locally but never sent to server (not so sure),
> ...
>
> Part of the problem is that the EDS API is prone to race conditions. This needs
> to be fixed first, as discussed with the EDS developers:
> http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html
>
> Since that discussion I have implemented automatic restore from backup, which
> has
> changed my view on the necessary APIs a bit: it would be nice to store
> items with a specific REV or LAST-MODIFIED if the libebook/libecal user
> knows what he is doing. Not bumping these fields when restoring an items
> has the advantage that other clients which were in sync with the
> restored data don't see any unnecessary changes.
>
> The other part of the problem is getting a set of item ID + revision string
> (REV for contacts, LAST-MODIFIED for event/tasks) in an atomic way. I'm not
> sure whether the current methods are really atomic. But worse, they are also
> much slower than they could be because we have to transmit the whole content of
> the database via D-Bus just to extract the much smaller set of required
> information.
>
> Ross wanted to work on a call to return pairs of UID+REV for libebook. I don't
> think he got very far with that, though. I think this is a fairly import
> optimization.
------- Comment #3 From pohly 2009-08-10 02:17:11 PST (-) [reply] -------
(In reply to comment #2)
> Do we need to impl this concurrent feature for all backends? (groupwise,
> google, exchange, etc.)
Doing it for the file backend would be enough.
> When is eds-dbus port ready?
Ross, what is the timeline for merging this into master?
> Do we need work on this feature on both bonobo and
> dbus? If so, which one has more priority?
I'd say D-Bus is more important, but I don't think upstream would merge this
unless we also do Bonobo/CORBA - it remains alive. Ross, do you know what the
plans are regarding that?
------- Comment #4 From Ross Burton 2009-08-10 02:28:49 PST (-) [reply] -------
We're merging the addressbook port in the next week or so, but I expect moblin
2.1 to ship eds-dbus still.
Please work on eds-dbus first so that we can ship this code.
------- Comment #5 From pohly 2009-08-10 03:14:18 PST (-) [reply] -------
(In reply to comment #4)
> We're merging the addressbook port in the next week or so, but I expect moblin
> 2.1 to ship eds-dbus still.
>
> Please work on eds-dbus first so that we can ship this code.
Is that the "dbus" branch in git.gnome.org? Do you rebase that branch or is it
safe to pull from it and create the new API in a feature branch based on the
"dbus" branch?
------- Comment #6 From Ross Burton 2009-08-10 06:41:35 PST (-) [reply] -------
At present, and I expect for 2.1 unless magic happens, we're shipping eds-dbus
from git.o-hand.com.
------- Comment #7 From Chen Congwu 2009-08-10 18:24:46 PST (-) [reply] -------
So I will work on this repo and provide patch against this.
(In reply to comment #6)
> At present, and I expect for 2.1 unless magic happens, we're shipping eds-dbus
> from git.o-hand.com.
------- Comment #8 From Chen Congwu 2009-08-11 18:13:27 PST (-) [reply] -------
After reading the eds-dbus code, I suspect "RETURN-REV" capability can't be
implemented for existing non-atomic calls.
The reason is: the dbus call does not return "revision" or "Contact", the
changed item is asynchronously popped up by another signal ("contacts-changed",
etc.). What's worse, the signal has a buffering mechanism, it will not emit as
soon as a contact is changed(maybe delayed to a later point to pop up a batch
of changes).
Two solutions: 1) change the dbus interface (incompatible) 2) Use the
workaround which was used by syncevolution in libebook (get the whole contact
again by another dbus call, which still can not guarantee the correct semantic
(the contacts may already be changed by another client).
I suggest not support "RETURN-REV" capability in existing non-atomic calls. For
the new added atomic calls, we can use a different dbus interface which will
return the "revision" information from the dbus method call.
Ross and Patrick, do you think so?
------- Comment #9 From pohly 2009-08-11 23:36:23 PST (-) [reply] -------
(In reply to comment #8)
> After reading the eds-dbus code, I suspect "RETURN-REV" capability can't be
> implemented for existing non-atomic calls.
>
> The reason is: the dbus call does not return "revision" or "Contact", the
> changed item is asynchronously popped up by another signal ("contacts-changed",
> etc.). What's worse, the signal has a buffering mechanism, it will not emit as
> soon as a contact is changed(maybe delayed to a later point to pop up a batch
> of changes).
> Two solutions: 1) change the dbus interface (incompatible)
Isn't that interface EDS internal anyway and thus can be changed as necessary?
Packagers must be sure to not put incompatible libebook and EDS on the same
system, but that has always been the case. That packagers sometimes forgot
about the necessary "conflicts" entries in their packages is a different
problem...
> For
> the new added atomic calls, we can use a different dbus interface which will
> return the "revision" information from the dbus method call.
Using different communication paths with EDS to implement the old and new
update/delete calls smells like unnecessary code duplication to me. I'd rather
extend the protocol so that it works for the more advanced new calls and then
map the old ones to the new ones in libebook (they are intentionally strict
subsets).
------- Comment #10 From Ross Burton 2009-08-12 00:20:17 PST (-) [reply]
-------
I've been telling everyone who wants to talk to EDS via DBus directly not to
because the protocol isn't stable, and this is exactly why. We can change the
DBus protocol easily, what would the exact changes be?
------- Comment #11 From Chen Congwu 2009-08-12 00:47:52 PST (-) [reply]
-------
Thant's good, so I will change the dbus api.
The modification apis(create,remove,modify) need be extended to:
1) return the new rev in the dbus call
2) add a new input parameter "flags" to indicate different semantics (ignore
rev check, use rev check and do not update rev)
Another thing is can I take this assumption also to the backends? That is can I
modify existing backends apis instead of adding new apis? Personally I don't
think so (The backends api is not internal, there maybe third party backend
implementations existed).
(In reply to comment #10)
> I've been telling everyone who wants to talk to EDS via DBus directly not to
> because the protocol isn't stable, and this is exactly why. We can change the
> DBus protocol easily, what would the exact changes be?
------- Comment #12 From Ross Burton 2009-08-12 02:28:21 PST (-) [reply]
-------
The backend API is meant to be somewhat stable, but we've broken it anyway for
the DBus branch so if you want to break it more, do it soon!
------- Comment #13 From Chen Congwu 2009-08-21 08:27:40 PST (-) [reply]
-------
Created an attachment (id=2325)
--> (http://bugs.meego.com/attachment.cgi?id=2325) [details]
patch set for this issue
Ross & Patrick, this is the patch I provided for this issue, could you please
help review?
-------------
This patch set aims at solve eds atomic modification problem, see posts in
evolution-hackers mailing list.
The first 3 patches are api changes. The next 8 patches are:
0004 addressbook libebook (dbus client) new api implementation
0005 addressbook libedata-book (dbus serivce) new api implementation
0006 addressbook file backend new api implementation
0007 addressbook unit test
0008 calendar libecal (dbus client) new api implementation
0009 calendar libedata-cal (dbus service) new api implementaion
0010 calendar file backend new api implementaion
0011 calendar unit test
Interface changes and impact:
1. Dbus api has been extended. Applications use dbus directly will break
2. Backend virtual method has been changed. Old backends has to be changed
according to work with the new api (Even if it does not provide the new
capability)
3. libebook api has a small change (subjet to change): For the async
modification apis, "return-rev" capability requires the new revision
information
be returned to client by the user-supplied callback. Therefore the
callback function is changed to add another input parameter.
Mutlti-thread problems:
Added a multi-thread test for addressbook, see patch 0007. The test fails
because of a known bug in libdbus (Phantom OOM). With a patch found in the
mailinglist, the test can pass but sometimes client will block a while. Seems
this is also caused by libdbus or glib binding.
------- Comment #14 From pohly 2009-10-22 06:29:29 PST (-) [reply] -------
Without this feature, running syncs in the background is risky because of the
race conditions.
------- Comment #15 From Chen Congwu 2009-10-24 20:09:43 PST (-) [reply]
-------
More from Suyog: (The manual settings you need to set up)
> You can make the necessary synchronization settings for your device manually by following the instructions below:
>
>
>
> 1. Go to Sync menu on your device Usually the Sync menu is found from Menu grid/Tools or under Menu grid/Settings depending on your device.
>
> 2. Select and open "Sync" icon from the grid Press Options an select "New sync profile" from the opened view. DO NOT copy values from other profile.
>
> 3. Name the new profile or use the default name Select and open "Sync profile name" list item. Write the name to the opened text input field.
>
> 4. Select and open "Applications" list item Open each desired application from the list in turn.From the opened submenu, switch "Yes", if you want to synchronize the opened application. Set(write) the Remote Database as listed below for each application:
> for Contacts: ./Contact/Unfiled
> for Calendar: ./EventTask/Tasks
> for Notes: ./Note/Unfiled
> Set "Synchronization type" for each desired application to be "normal" or "both ways" (depending on the device).
>
> 5. Select and open "Connections settings" from the Sync profile list Set or write (depending on the setting) the following values:
> Server version: Leave the default value
> Server ID: Leave the default name
> Data Bearer: Internet
> Access point: Chose the internet access point
> Host address: https://sync.ovi.com/services/syncml
> Port: 443
> User name: suyog
> Password: ******************
> Allow sync requests: Leave the default value
> Accept all sync reqs.: Leave the default value
> Network authentication: This setting depends on the details of your data connectivity service. If you select "Yes", you have to fill also your Nokia account username and password
>
> You have now done your sync settings for your device. To synchronize your device go back to the sync instructions screen by pressing the button below.
>
------- Comment #16 From Chen Congwu 2009-10-24 20:11:17 PST (-) [reply]
-------
(In reply to comment #15)
Sorry, I just copy & pasted to a wrong bug entry...
------- Comment #17 From pohly 2009-11-25 00:56:44 PST (-) [reply] -------
Ross, as I said in our chat, we need to decide how to move forward with this
patches because they are needed for automatic sync. Therefore I am raising the
priority to P1 temporarily and assign this to you.
Next steps:
* check as many of the patches as you can
* rebase/update remaining patches according to your comments
* create bugzilla.gnome.org and request inclusion there (?)
------- Comment #18 From Ross Burton 2009-12-02 04:03:24 PST (-) [reply]
-------
As we'll shortly be switched to eds from upstream master, would it be possible
to rebase these patches on evolution-data-server from git.gnome.org?
------- Comment #19 From Chen Congwu 2009-12-02 21:44:00 PST (-) [reply]
-------
Ok, I will do this, you may have to wait 1~2 days as the patch is a little
large.
(In reply to comment #18)
> As we'll shortly be switched to eds from upstream master, would it be possible
> to rebase these patches on evolution-data-server from git.gnome.org?
------- Comment #20 From Chen Congwu 2009-12-06 01:18:24 PST (-) [reply]
-------
(In reply to comment #19)
Done, you may pull from
http://mob-sync1.sh.intel.com/evolution-data-server.git
> Ok, I will do this, you may have to wait 1~2 days as the patch is a little
> large.
>
> (In reply to comment #18)
> > As we'll shortly be switched to eds from upstream master, would it be possible
> > to rebase these patches on evolution-data-server from git.gnome.org?
------- Comment #21 From Chen Congwu 2010-01-10 22:07:00 PST (-) [reply]
-------
(In reply to comment #20)
Ross, do you have any plan for reviewing this?
> (In reply to comment #19)
> Done, you may pull from
> http://mob-sync1.sh.intel.com/evolution-data-server.git
>
> > Ok, I will do this, you may have to wait 1~2 days as the patch is a little
> > large.
> >
> > (In reply to comment #18)
> > > As we'll shortly be switched to eds from upstream master, would it be possible
> > > to rebase these patches on evolution-data-server from git.gnome.org?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 9 months
[Bug 1356] New: extend vCard field list (Memotoo, ScheduleWorld)
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=1356
Summary: extend vCard field list (Memotoo, ScheduleWorld)
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: ASSIGNED
Severity: normal
Priority: Medium
Component: SyncML
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-syncml-bugs(a)meego.bugs
Estimated Hours: 0.0
This is from http://bugzilla.moblin.org/show_bug.cgi?id=6303
Description From pohly 2009-09-21 07:45:26 PST (-) [reply]
Please include a detailed description as well as steps to reproduce the bug.
The following vCard properties are in use by Memotoo:
X-SKYPE-USERNAME:skype id
X-EVOLUTION-ASSISTANT-TEL:assistant's phone
X-EVOLUTION-PARENT:parents
X-EVOLUTION-CHILDREN:children
X-SYNCEVOLUTION-FBURL:http://www.memotoo.com/contactsIFB.php?uid=73fc9832...
None of them are currently detected by the Synthesis config.
We need to do three things:
1. figure out how we can have properties in the main configuration
which are not supported by the active backend
2. add X-SKYPE-USERNAME, X-EVOLUTION-PARENT, X-EVOLUTION-CHILDREN,
X-EVOLUTION-ASSISTANT-TEL; see bug #3473
3. map between X-SYNCEVOLUTION-FBURL and FBURL, see X-[EVOLUTION-]SPOUSE
Adding the new properties without solving 1 has the undesirable effect that the
SyncML server gets wrong information about the client, because the DevInf would
include properties not supported by the data source.
------- Comment #1 From pohly 2009-09-23 07:37:35 PST (-) [reply] -------
ScheduleWorld also supports setting a timezone for the user, which is then sent
as the TZ property. This falls into the same category as X-SKYPE-USERNAME: we
want it in the field list and file backend, but not in Evolution (not supported
there).
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
11 years, 9 months