6:04 a.m.
http://bugzilla.moblin.org/show_bug.cgi?id=8496
Summary: SAN generation: always use "base" type (text/x-vcard,
text/x-vcalendar)
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: Undecided
Component: *Feature Request
AssignedTo: congwu.chen(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Congwu, did you see this discussion on the Synthesis mailing list?
--------------------------------------------------------------
From: Lukas Zeller <luz(a)synthesis.ch>
To: Ohly, Patrick <patrick.ohly(a)intel.com>
Cc: Chen, Congwu <congwu.chen(a)intel.com>, os-libsynthesis(a)synthesis.ch
<os-libsynthesis(a)synthesis.ch>
Subject: Re: [os-libsynthesis] More calendar tests problems
Date: 12/02/2009 05:05:56 PM (Wed, 2 Dec 2009 16:05:56 +0000)
Hi Patrick,
On Dec 2, 2009, at 16:08 , Patrick Ohly wrote:
> I doubt (but haven't tried to prove) that the MIME type in
the SAN
> would really influence type negotiation, I'd assume it is used as a
> safer identifier for the store than the name is, but as long as you
> use a mime type that is valid for that datastore I'd expect it would
> trigger a sync in the same way as a manual start would.
So you are proposing to always use "text/x-vcalendar" (or its binary
equivalent) even if we would prefer "text/calendar"? That might work,
except for those hypothetical handsets which *only* support
"text/calendar".
Yes :-)
--------------------------------------------------------------
Is this something that we should implement?
We could build the logic so that unless "type" forces a specific type
(exclamation mark), we always use the older format. That applies to both
contacts (text/x-vcard) as well as events (text/x-vcalendar).
--
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.
12:30 p.m.
New subject: [Bug 8496] SAN generation: always use "base" type (text/x-vcard, text/x-vcalendar)
http://bugzilla.moblin.org/show_bug.cgi?id=8496
--- Comment #1 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-07 17:30:55 PST
---
(In reply to comment #0)
Congwu, did you see this discussion on the Synthesis mailing list?
--------------------------------------------------------------
From: Lukas Zeller <luz(a)synthesis.ch>
To: Ohly, Patrick <patrick.ohly(a)intel.com>
Cc: Chen, Congwu <congwu.chen(a)intel.com>, os-libsynthesis(a)synthesis.ch
<os-libsynthesis(a)synthesis.ch>
Subject: Re: [os-libsynthesis] More calendar tests problems
Date: 12/02/2009 05:05:56 PM (Wed, 2 Dec 2009 16:05:56 +0000)
Hi Patrick,
On Dec 2, 2009, at 16:08 , Patrick Ohly wrote:
>> I doubt (but haven't tried to prove) that the MIME type in the SAN
>> would really influence type negotiation, I'd assume it is used as a
>> safer identifier for the store than the name is, but as long as you
>> use a mime type that is valid for that datastore I'd expect it would
>> trigger a sync in the same way as a manual start would.
>
> So you are proposing to always use "text/x-vcalendar" (or its binary
> equivalent) even if we would prefer "text/calendar"? That might work,
> except for those hypothetical handsets which *only* support
> "text/calendar".
Yes :-)
--------------------------------------------------------------
Is this something that we should implement?
We could build the logic so that unless "type" forces a specific type
(exclamation mark), we always use the older format. That applies to both
contacts (text/x-vcard) as well as events (text/x-vcalendar).
I saw it.
Why do we need to force user to always use text/x-vcalendar even if he
intentionally set it to text/calendar? Is that necessary? Reporting an error to
user during sync is also reasonable in my opinion.
The baseline is we will set 'text/x-vcalendar' as default.
--
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.
7:27 p.m.
New subject: [Bug 8496] SAN generation: always use "base" type (text/x-vcard, text/x-vcalendar)
http://bugzilla.moblin.org/show_bug.cgi?id=8496
--- Comment #2 from pohly <patrick.ohly(a)intel.com> 2009-12-08 00:27:59 PST ---
(In reply to comment #1)
> We could build the logic so that unless "type" forces
a specific type
> (exclamation mark), we always use the older format. That applies to both
> contacts (text/x-vcard) as well as events (text/x-vcalendar).
I saw it.
Why do we need to force user to always use text/x-vcalendar even if he
intentionally set it to text/calendar?
According to Lukas, picking "text/x-vcalendar" for the SAN does not mean that
the sync itself will be done in that mode. The normal auto-negotiation of the
preferred mode still takes place *if* the phone starts to sync.
Is that necessary? Reporting an error to
user during sync is also reasonable in my opinion.
The baseline is we will set 'text/x-vcalendar' as default.
That doesn't "look right". In a normal config, this says "our source
'calendar'
prefers vCalendar 1.0", which is not true. We prefer iCalendar 2.0 whenever
possible.
So suppose we configure the source with 'text/calendar', because we want the
Synthesis engine to pick that mode if the peer supports it. Now we sync against
a peer which does not support it. We put 'text/calendar' into the SAN. What
happens now?
I expect that the phone will either refuse to sync completely or skip the
unsupported calendar source. In both cases, no good error message will be
presented to the user of SyncEvolution.
Suppose that we had used 'text/x-vcalendar' in the SAN. The sync would start,
the Synthesis engine would determine that the peer only supports vCalendar 1.0,
and the sync completes using that mode.
In other words, implementing a "downgrade" of data formats when generating the
SAN makes it easier to write a configuration that works. It is not essential,
because there's always a config which has the same effect.
--
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.
8:15 p.m.
New subject: [Bug 8496] SAN generation: always use "base" type (text/x-vcard, text/x-vcalendar)
http://bugzilla.moblin.org/show_bug.cgi?id=8496
--- Comment #3 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-08 01:15:21 PST
---
(In reply to comment #2)
> Is that necessary? Reporting an error to
> user during sync is also reasonable in my opinion.
> The baseline is we will set 'text/x-vcalendar' as default.
That doesn't "look right". In a normal config, this says "our source
'calendar'
prefers vCalendar 1.0", which is not true. We prefer iCalendar 2.0 whenever
possible.
A bit confused. I was thought if we set it, we effectively mean we
prefer
vCalendar 1.0 and also accept iCalendar 2.0. The devinf we sent may correctly
lead a reasonable peer to send items in vCalendar 1.0 format. Any wrong?
So suppose we configure the source with 'text/calendar',
because we want the
Synthesis engine to pick that mode if the peer supports it.
This is the key. So
when user sets this, he wants to "Syncing with
text/calendar' if possible but please fall back to 'text/x-vcalendar' if not
supported. In the SAN case, the fallback mechanism will not work, this is why
we need to fix this bug, right?
In other words, implementing a "downgrade" of data formats
when generating the
SAN makes it easier to write a configuration that works. It is not essential,
because there's always a config which has the same effect.
--
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.
10:14 p.m.
New subject: [Bug 8496] SAN generation: always use "base" type (text/x-vcard, text/x-vcalendar)
http://bugzilla.moblin.org/show_bug.cgi?id=8496
--- Comment #4 from pohly <patrick.ohly(a)intel.com> 2009-12-08 03:14:20 PST ---
(In reply to comment #3)
(In reply to comment #2)
> > Is that necessary? Reporting an error to
> > user during sync is also reasonable in my opinion.
> > The baseline is we will set 'text/x-vcalendar' as default.
>
> That doesn't "look right". In a normal config, this says "our
source 'calendar'
> prefers vCalendar 1.0", which is not true. We prefer iCalendar 2.0 whenever
> possible.
A bit confused. I was thought if we set it, we effectively mean we prefer
vCalendar 1.0 and also accept iCalendar 2.0. The devinf we sent may correctly
lead a reasonable peer to send items in vCalendar 1.0 format. Any wrong?
Your description is correct. However, the only reason for using
"text/x-vcalendar" in SyncEvolution with Evolution backends is to work around
broken peers who cannot handle the auto-negotiation correctly or pick iCalendar
2.0 although they don't implement it properly.
Evolution itself only works with iCalendar 2.0, which is therefore (and because
it is more capable) our preferred format.
> So suppose we configure the source with 'text/calendar',
because we want the
> Synthesis engine to pick that mode if the peer supports it.
This is the key. So when user sets this, he wants to "Syncing with
text/calendar' if possible but please fall back to 'text/x-vcalendar' if not
supported. In the SAN case, the fallback mechanism will not work, this is why
we need to fix this bug, right?
Exactly.
--
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.
5:59 p.m.
New subject: [Bug 8496] SAN generation: always use "base" type (text/x-vcard, text/x-vcalendar)
http://bugzilla.moblin.org/show_bug.cgi?id=8496
--- Comment #5 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-15 22:59:34 PST
---
(In reply to comment #4)
Implemented in
http://git.moblin.org/cgit.cgi/syncevolution/commit/?h=phone&id=eee8b...
--
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.
4:14 p.m.
New subject: [Bug 8496] SAN generation: always use "base" type (text/x-vcard, text/x-vcalendar)
http://bugzilla.moblin.org/show_bug.cgi?id=8496
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #6 from Chen Congwu <congwu.chen(a)intel.com> 2010-02-21 21:14:24 PST
---
Considering this been fixed.
--
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.
3:27 a.m.
New subject: [Bug 8496] SAN generation: always use "base" type (text/x-vcard, text/x-vcalendar)
http://bugzilla.moblin.org/show_bug.cgi?id=8496
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
Resolution|FIXED |INTEGRATED
--- Comment #7 from pohly <patrick.ohly(a)intel.com> 2010-02-24 08:27:44 PST ---
Integrated in 1.0 beta 2 = 0.99.11. Let's consider this closed and reopen if
testing with phones fails.
--
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.
4589
days inactive
4668
days old
syncevolution-issues@syncevolution.org
7 comments
1 participants
participants (1)
-
bugzilla＠moblin.org