6:05 p.m.
On Tue, 2009-09-01 at 03:20 +0100, Zheng, Yanshuang wrote:
I have run sync to check the supported attributes/fields when
syncing with different servers, which may provide different fields on
its web interface. It is somewhat difficult for us to parse all of
them, or find a matched field to display them on client. I’d like to
summarize the status from user experience and share with you, even
though we have keep README for each
server.( http://git.moblin.org/cgit.cgi/syncevolution/tree/test)Any
question/comment is welcome J
This is an excellent overview. We should look into all of these problems
and check how we can minimize the user impact. In some cases it might
not be possible (if Evolution doesn't have a field, we can't force it to
show the value...) but sometimes it may be possible to do something
(like for the single cell phone case, #5633).
We also need to think about how we test this. Currently client-test only
supports "homogeneous" tests: store in EDS, send to server, copy back
into EDS. Much more challenging are the syncs where the peer is the
server or some other device, which we don't cover right now.
We could set up combinations of file sync source and some other sync
source: the file sync source supports anything that the Synthesis
configuration (field list) supports. If we implement #5046 "raw file
sync source", then it can be truly used to store anything the server
supports, which would allow us to test "item created on server" or
"created by other device" situations.
In any case, the goals are:
* extend the field list configuration so that all server
properties can be represented => no properties lost when storing
in current file sync source
* remap the internal fields into something that Evolution
understands, if possible
* for anything that we cannot solve, document the remaining issues
in the test/README.* files
Yanshuang, can you help us get started with this by attaching test cases
to the report? I'm looking for the item data as sent by the servers;
this is part of the sysynclib_linux.html logs, visible after unfolding
with the "+++" symbol at the top of the file.
This may lead to a third category. "Not Sent" - data is on server, but
not sent to clients.
Now more specific comments:
Below is the list of fields that behave not normally during sync,
including
Missed – when refresh it from server, the field/value get missed in
EDS. Thus no such value is kept in backend. Often Evolution doesn’t
have user interface for these fields.
Not shown – when refresh them from server, they have no mapped user
interfaces to display, although there keep value in EDS. “moblin only”
means this field has interface on Evolution(fedora/ubuntu), but not on
Moblin.
[Scheduleworld]
Missed:
Addressbook - Latitude, Longitude, Time Zone, IP/SIP phone, Radio,
Assistant phone, Callback phone, Company phone, Video phone, Home
video phone, Work video phone,
Video phone might have the same problem as TEL:TYPE=CELL (only
TYPE=VIDEO supported, but no combination).
Facebook ID, Google talk, Skype, Net meeting, Gizmo, Twitter, LDAP
server, calCAPURI, calCalAdrURI, calOtherCalURI, calOtherFBURLs,
calOtherCAPURIs, calOtherCalAdrURIs;
What are these cal* properties?
Calendar– status, attendee;
That's surprising. Evolution supports meeting attendees and their
status.
Tasks– Recurrence, Exception, attendees, show me as(TRANSP)
Not shown:
Addressbook- Primary phone, Pager; moblin onlyà[Prefix, Suffix, Middle
name, Spouse, Anniversary, Job title, Profession, Manager, Assistant,
Blog URL, calCalURI, Free/Busy URL]
Calendar– moblin onlyà[categories, show me as, privacy]
Tasks– Location, moblin onlyà[when start, no start, Duration, Status,
Percent]
Problematic:
Addressbook–
1)sync “Assistant” back to Scheduleworld, it will be displayed not in
field “Assistant”, but in “Assistant Phone”
X-[EVOLUTION-]ASSISTANT clearly isn't the same as TEL;TYPE=ASSISTANT (or
whatever ScheduleWorld uses for "Assistant Phone").
2)sync “Home fax” and “other fax” back to Scheduleworld, it will
show
empty on these two fields
3)ISDN is parsed as TEL, thus it will be moved to “Other Phone” after
sync
4)Field “Other”, including address, city, state, postal, country,
p.o.box, will show empty in Evolution(test with 2.24 on fedora10,2.26
on ubuntu9.04), although ADR is not empty in EDS. While on Moblin with
evolution-anjal-2.27, we don’t encounter this.
5)values in Email1~Email8 may be reversed if sync-ed back to server.
E.g. Email1 keep value originally filled in email8; Email2 keep value
originally filled in email7; and so on)
[Funambol]
Missed:
N/A
Not applicable because the server supports so few fields that Evolution
doesn't miss any of them?
Not shown:
Addressbook- moblin onlyà[Work title]
Calendar– reminder
Like attendee above, this is something which should work.
Problematic:
Addressbook– 1)”Work>>Company phone” is parsed as TEL, thus it will be
moved to “Other Phone” after sync. If sync back to Funambol, it will
be moved to “Other phone1” and replace 2)values in ”Other phone 1” and
“Other Phone 2” may be exchanged after sync back to Funambol.
Looks like 4598 "Funambol: Company phone property will lost in syncing
addressbook"
[Google]
Missed:
Addressbook– Nickname, Website>>Home, Website>>work, Website>>Home
page, Website>>FTP, Website>>Blog, Website>>Proile,
Website>>Other,
Birthday, Anniversary, Other dates, Person>>Spouse, Person>>child,
Person>>mother, Person>>father, Person>>parent, Person>>brother,
Person>>sister, Person>>friend, Person>>relative,
Person>>domestic
partner, Person>>manager, Person>>assistant, Person>>Partner,
Person>>referred by, Google talk, AIM, Yahoo, Skype, QQ, MSN, ICQ,
Jabber, Facebook ID, Custom>>value, Custom>>label
I suspect that most of these properties are not made available to a
SyncML client by Google.
Not shown:
Addressbook- Pager
Problematic:
Addressbook– 1) sync “Other address” from Google to client, it will
show empty in Evolution(test with 2.24 on fedora10,2.26 on
ubuntu9.04), although ADR is not empty in EDS. While on Moblin with
evolution-anjal-2.27, we don’t encounter this.
--
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.