Patrick Ohly | 1 Sep 2009 09:53
Picon
Favicon
Gravatar

sync - Attributes mapping with servers

Hi,

forwarding with Yanshuang's permission.... will reply here shortly.

-------- Forwarded Message --------
From: Zheng, Yanshuang <yanshuang.zheng <at> intel.com>
Subject: sync - Attributes mapping with servers
Date: Tue, 1 Sep 2009 03:20:09 +0100

Hi all, 

   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

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
(Continue reading)

Patrick Ohly | 1 Sep 2009 10:05
Picon
Favicon
Gravatar

Re: sync - Attributes mapping with servers

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
(Continue reading)

Zheng, Yanshuang | 1 Sep 2009 10:26
Picon
Favicon

Re: sync - Attributes mapping with servers

 

 

>-----Original Message-----

>From: Ohly, Patrick

>Sent: 200991 16:05

>To: Zheng, Yanshuang

>Cc: Zhang, Jingke; Ou, Guannan; Pan, Weibin; Wang, Ning W; SyncEvolution

>Subject: Re: [SyncEvolution] sync - Attributes mapping with servers

>

 

>

 

>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.

Sure, I will get these cases from log and share with all.

 

>> [Scheduleworld]

>>....

>> Facebook ID, Google talk, Skype, Net meeting, Gizmo, Twitter, LDAP

>> server, calCAPURI, calCalAdrURI, calOtherCalURI, calOtherFBURLs,

>> calOtherCAPURIs, calOtherCalAdrURIs;

>

 

>What are these cal* properties?

Not know what exactly they are, sounds like personal calendar related with this contact. Not so popular yet.

 

>> [Funambol]

>>

 

>> Missed:

>>

 

>> N/A

>

 

>Not applicable because the server supports so few fields that Evolution

>doesn't miss any of them?

Yeah… J

 

Thanks,

Yanshuang

_______________________________________________
SyncEvolution mailing list
SyncEvolution@...
http://lists.syncevolution.org/listinfo/syncevolution
Patrick Ohly | 1 Sep 2009 11:54
Picon
Favicon
Gravatar

status 2009-09-01

Hi!

You've seen the schedule announcement. Work towards that is chucking
along:

Development:
      * Yongsheng: improved log file handling (#5215, merged), keyring
        support in syncevolution (#3604), create missing Full Name
        (#5633)
      * Congwu: EDS API patch completed (to be reviewed by Ross) and
        SyncEvolution also adapted (to be reviewed by Patrick),
        investigations for OBEX client implementation
      * Patrick: libecal crash with Etc/UTZ TZID, D-Bus server
        reimplementation, fixes for bugs/incomplete implementation in
        gdbus

Noteworthy new issues:
      * #5633: Blackberry -> Funambol -> SyncEvolution syncs don't send
        a Full Name (FN) property, which is expected by Evolution and
        the Contacts app in Moblin (at least it was expected a while
        ago). We'll create that property from N (the name components)
        when importing into Evolution.
      * #5635: Memotoo - some reports by users about problems (one
        already fixed on the server), so we started interoperability
        testing
      * #3427: resending a certain message is not handled by the
        Funambol and ScheduleWorld servers

--

-- 
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.
chen | 1 Sep 2009 11:03

Re: why not a forum

Patrick Ohly <patrick.ohly <at> ...> writes:

> 
> On Mon, 2009-08-31 at 12:15 +0100, Thierry Chen wrote:
> >  why do you still use mailing lists for that kind of service? Is there
> > one advantage against forums ???
> 
> Forums have the disadvantage that you need to visit a web site when want
> to reply. In some forums you even have to poll the web site to read what
> others have written. This doesn't fit into my way of working, which is
> email-centric (like that of most open source developers).
> 
> >  I see only disavantages. First you can't make search on pevious
> > messages to see if your problem has been discussed sooner
> 
> That's what mailing list archives are for. We even have multiple
> different interfaces so that you can pick one that you like (in contrast
> to a forum, which comes with one interface that at best can be
> customized to look differently).
> 
> SyncEvolution:
> http://lists.syncevolution.org/pipermail/syncevolution/
> http://dir.gmane.org/gmane.comp.mobile.syncevolution
> http://www.mail-archive.com/syncevolution-iSTEHRHt8w9N2k9L2T2VtNi2O/JbrIOy
<at> public.gmane.org/
> 
> For bug reports:
> http://lists.syncevolution.org/pipermail/syncevolution-issues/
> http://dir.gmane.org/gmane.comp.mobile.syncevolution.issues
>
http://www.mail-archive.com/syncevolution-issues-iSTEHRHt8w9N2k9L2T2VtNi2O/JbrIOy <at>
public.gmane.org/
> 
> > Or could someone tell me how to use mailing lists correctly ?
> 
> You can use gmane as a web forum. View a message:
> http://news.gmane.org/gmane.comp.mobile.syncevolution
> Then use the "Follow up" option in the upper right corner:
> http://post.gmane.org/post.php?group=gmane.comp.mobile.syncevolution&followup=231
> 

Thanks a lot for your answers Patrick. I'll try to use mailing lists technics.
Your subscription page needs perhaps only some information about howto use it.
But the problem is that forums are very intuitives and let people find
information quicly without having to learn any technics.
Your point of you is a developper's one but somebody who just looks for some
answer to a pb is different :-)
Patrick Ohly | 1 Sep 2009 13:25
Picon
Favicon
Gravatar

Re: why not a forum

On Tue, 2009-09-01 at 10:03 +0100, chen wrote:
> Thanks a lot for your answers Patrick. I'll try to use mailing lists technics.
> Your subscription page needs perhaps only some information about howto use it.

That depends on which page you mean. The support page lists this kind of
information:
http://syncevolution.org/support

The actual subscriber page then is provided by the mailing list
software. I assume you went directly to that. I didn't know that
customizing that page is possible, but your questions regarding a forum
motivated me to look a bit closer. Now the information is hopefully a
bit easier to find.

> But the problem is that forums are very intuitives and let people find
> information quicly without having to learn any technics.
> Your point of you is a developper's one but somebody who just looks for some
> answer to a pb is different :-)

True, but looking for the solution to a problem is never easy. If you
want good answers, some time and effort is normally necessary and
expected when asking the question. It shouldn't be any harder than
necessary, of course.

We are still experimenting with ways how users can report problems.
Feedback is welcome.

--

-- 
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.
Patrick Ohly | 1 Sep 2009 13:31
Picon
Favicon
Gravatar

Re: sync evolution/horde

Hello Thierry!

Please use group-reply in your mail program so that the list gets a copy
of your emails.

On Tue, 2009-09-01 at 08:32 +0100, Thierry Chen wrote:
[use funambol template, edit config]
> THIS IS BETTER, THANKS.
> Now I've completed my config.ini and syncevolution horde shows that
> error (log Level 3):
> 
> "[ERROR] no sources active, check configuration"
> 
> my config.ini:
> uri = contacts
> syncURL = http://ns36227.ovh.net/horde/rpc.php
> username = XXXXX@...
> password = XXXXX
>  logdir = /home/kmc/Desktop/syncevolution
>  loglevel =3 
> deviceId = sc-pim-1ac057dc-1cff-4147-8a7d-6b47cecf60b3
> enableWBXML = 0
> WebURL = http://www.webologix.com
> ConsumerReady = 1

You have to enable those data sources which work with Horde and set the
right URI. Start with the horde/sources/addressbook/config.ini. Contacts
are more likely to work. Later you can also enable calendar, tasks and
notes.

--

-- 
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.
Jussi Kukkonen | 1 Sep 2009 13:39
Picon

Re: next generation syncevo-dbus-server

Patrick Ohly wrote:
> On Mon, 2009-08-31 at 12:23 +0100, Jussi Kukkonen wrote:
>> I've been trying to figure out the progress handling logic, but
>> without much success. The idea was to move some of it into the
>> server to make sure different clients would provide consistent
>> info, but it's not so easy. Any comments on these? 1. progress as
>> percentage: This will always be a wild guess, because we can't know
>> what the server will give us, but making just one wild guess is
>> probably better than many?
> 
> I agree. This should be progress by source, so that a client which
> wants to provide detailed information can do so. Overall progress
> then could be presented as a combination of the progress of the
> active sources - if all of them provide that information.

Ahem, I actually copy-pasted this bit away from the text in error:

  In addition to a "total progress" guesstimate, we should provide the
  actual counts (as in "received 3/7 contacts") per source, since we'll
  be calculating those for the percentage anyway...

This is the "additional" progress signal I was talking about earlier. I
just hadn't finalized it yet...

>> 2. progress messages: "Receiving %s", "Sync finished", ... Clients
>> can get this information from the synthesis signal fairly easily.
> 
> Unless we can wrap a nicer (and fully documented) API around this,
> then we probably should stick to the Synthesis signals (but see below
> about global state).
> 
>> 3. error messages: "Server authorization failed", "No space left",
>> ... Clients can get this information from synthesis signal, but
>> it's not easy.
> 
> Error messages are difficult because we don't have a concept of 
> localization in the D-Bus API.
> 
>> The latter two seem like something the clients can deduce from the 
>> synthesis signal (with proper documentation they could even do it 
>> consistently). I think they should be only implemented if we really
>> aim to remove the synthesis signal at some point.
>> 
>> The first one seems somewhat useful. Should I just add that as a
>> variable to ProgressSignal?
> 
> There's something more fundamentally missing. Suppose a client
> attaches to a running session. How does it get the information about
> the current state of the session (sync running, active sources,
> requested and real sync modes, ...)?

[clip]
Yes, sorry for the missing note, I fully agree with what you wrote and I
think we agree on the general signaling idea as well:

The "additional" progress signal I mentioned earlier should take care of
the progress part, we can also add a GetProgress() method if it seems
necessary. I hadn't yet designed this but it should look something like
this:

   signal StillUnnamedProgressSignal
     out UINT32 progress
     ARRAY of STRUCT (STRING source, UINT32 mode,
                      UINT32 prepare_current, UINT32 prepare_total,
                      UINT32 receive_current, UINT32 receive_total,
                      UINT32 send_current, UINT32 send_total)

In a way it's a waste to send all of that when on thing changes, but I
think it makes sense. The above does not include requested sync mode. Is
that needed? Anything else missing?

What a simple application might still want is an easier error indication
(Frederik already commented on this). What I was considering was
modifying SyncEnd like this:

   signal SyncEnd
     out UINT32 return
     ARRAY of STRUCT (STRING source, UINT32 return_value)

Does this make sense if we just forward the PEV_SYNCEND return values in
the source return values? I think it does because most clients could
then skip the synthesis progress signal alltogether and use the two
signals above...

  - Jussi
Jussi Kukkonen | 1 Sep 2009 15:12
Picon

Re: next generation syncevo-dbus-server

Ok, tried to incorporate the comments you guys gave. I chatted with 
Patrick and we came to the conclusion that we should be able to get rid 
of the synthesis signal altogether by having to signals (Status and 
Progress) ... I'm going to look through the sync-ui code for any gotchas 
but I think this is true, and have updated the API proposal.

I'm still not too fond of the current GetReports idea (using hash keys 
like "source-addressbook-sent") but I've tried and can't come up with a 
proposal that would have the same features and a sane API. It'll do.

Changes:
  * Sync() now has the forgotten "mode" variable for sources
  * renamed SessionReady to SessionCreated, because that's what it is.
    Moved session.Close() to server.CloseSession() so it can be called
    before the session is actually created.
  * progress signal reworked: signal "Status" is for sync and source
    status changes and "Progress" includes the whole known progress state
    for the sync. There are matching Get-functions for both.
  * config functions now have a BOOLEAN variable "template"
    for accessing templates. Note that the functions in the session
    interface refer to the server specified in StartSession, so creating
    a config from template looks like this:
       server.GetConfigs(true)
       // pick a template here ...
       config = Server.GetConfig("chosen_template", true)
       // modify configuration here ...
       session = server.StartSession ("my_config")
       // wait for SessionCreated here...
       session.SetConfig(false, config)
       session.Close()
    Sound sensible? One could also start the session earlier if that
    makes more sense in the client.

  - Jussi

---

org.syncevolution.Server

   GetConfigs
     in BOOLEAN template
     out ARRAY of STRING server

   GetConfig
     in STRING server
     in BOOLEAN template
     out DICT (STRING source, DICT (STRING key, STRING value))

       [NOTE: outer dictionary contains a dictionary for every source and
        one dictionary for server config]

   GetReports
     in STRING server
     in UINT32 start
     in UINT32 count
     out ARRAY of DICT (STRING key, STRING value)

       [NOTE: returns a maximum of 'count' reports (dictionaries),
        starting from index 'start' (going from latest to oldest)]

   StartSession
     in STRING server
     out OBJECT_PATH session
   CloseSession
     in OBJECT_PATH session
   GetSessions
     out ARRAY of STRUCT (OBJECT_PATH path, BOOLEAN created)
   signal SessionCreated
     out OBJECT_PATH path
   signal SessionEnd
     out OBJECT_PATH path

     [NOTE: StartSession returns immediately, but the session object only
      exists when SessionCreated is signalled.]

org.syncevolution.Session

   Sync
     STRING mode
     in ARRAY of STRUCT (STRING sources, STRING mode)

     [NOTE: valid values for mode are same as in syncevolution config.
      If array is non-empty, only the sources included will be synced.
      If mode is empty the value from configuration will be used]

   Abort
   Suspend

   signal Status
     out STRING status
     out INT32 error
     out ARRAY of STRUCT (STRING source, STRING status, INT32 error)
   GetStatus
     out STRING status
     out INT32 error
     out ARRAY of STRUCT (STRING source, STRING status, INT32 error)

     [NOTE: valid values for status:
      "idle","running", "aborting", "suspending", "failed", "done"]

   signal Progress
     out INT32 progress
     out ARRAY of STRUCT (STRING source, STRING mode,
                          INT32 prepare_current, INT32 prepare_total,
                          INT32 receive_current, INT32 receive_total,
                          INT32 send_current, INT32 send_total)
   GetProgress
     out INT32 progress
     out ARRAY of STRUCT (STRING source, STRING mode,
                          INT32 prepare_current, INT32 prepare_total,
                          INT32 receive_current, INT32 receive_total,
                          INT32 send_current, INT32 send_total)

   GetConfig
     in BOOLEAN template
     out DICT (STRING source, DICT (STRING key, STRING value))
   SetConfig
     in BOOLEAN template
     in DICT (STRING source, DICT (STRING key, STRING value))
   UpdateConfig
     in BOOLEAN template
     in DICT (STRING source, DICT (STRING key, STRING value))

       [NOTE: outer dictionary contains a dictionary for every source and
        one dictionary for server config]

   GetReports
     in UINT32 start
     in UINT32 count
     out ARRAY of DICT (STRING key, STRING value)

       [NOTE: returns a maximum of 'count' reports (dictionaries),
        starting from index 'start' (going from latest to oldest)]
Zhu, Yongsheng | 1 Sep 2009 15:22
Picon
Favicon

Re: next generation syncevo-dbus-server

>  signal StillUnnamedProgressSignal
>     out UINT32 progress
>     ARRAY of STRUCT (STRING source, UINT32 mode,
>                      UINT32 prepare_current, UINT32 prepare_total,
>                      UINT32 receive_current, UINT32 receive_total,
>                      UINT32 send_current, UINT32 send_total)
In this signal, does 'prepare' mean what the client prepares data items before sync? Could these 3 kinds of
actions occur at the same time? 

Cheers,
Yongsheng

-----Original Message-----
From: syncevolution-bounces@...
[mailto:syncevolution-bounces@...] On Behalf
Of Jussi Kukkonen
Sent: Tuesday, September 01, 2009 7:39 PM
To: SyncEvolution
Subject: Re: [SyncEvolution] next generation syncevo-dbus-server

Patrick Ohly wrote:
> On Mon, 2009-08-31 at 12:23 +0100, Jussi Kukkonen wrote:
>> I've been trying to figure out the progress handling logic, but
>> without much success. The idea was to move some of it into the
>> server to make sure different clients would provide consistent
>> info, but it's not so easy. Any comments on these? 1. progress as
>> percentage: This will always be a wild guess, because we can't know
>> what the server will give us, but making just one wild guess is
>> probably better than many?
> 
> I agree. This should be progress by source, so that a client which
> wants to provide detailed information can do so. Overall progress
> then could be presented as a combination of the progress of the
> active sources - if all of them provide that information.

Ahem, I actually copy-pasted this bit away from the text in error:

  In addition to a "total progress" guesstimate, we should provide the
  actual counts (as in "received 3/7 contacts") per source, since we'll
  be calculating those for the percentage anyway...

This is the "additional" progress signal I was talking about earlier. I
just hadn't finalized it yet...

>> 2. progress messages: "Receiving %s", "Sync finished", ... Clients
>> can get this information from the synthesis signal fairly easily.
> 
> Unless we can wrap a nicer (and fully documented) API around this,
> then we probably should stick to the Synthesis signals (but see below
> about global state).
> 
>> 3. error messages: "Server authorization failed", "No space left",
>> ... Clients can get this information from synthesis signal, but
>> it's not easy.
> 
> Error messages are difficult because we don't have a concept of 
> localization in the D-Bus API.
> 
>> The latter two seem like something the clients can deduce from the 
>> synthesis signal (with proper documentation they could even do it 
>> consistently). I think they should be only implemented if we really
>> aim to remove the synthesis signal at some point.
>> 
>> The first one seems somewhat useful. Should I just add that as a
>> variable to ProgressSignal?
> 
> There's something more fundamentally missing. Suppose a client
> attaches to a running session. How does it get the information about
> the current state of the session (sync running, active sources,
> requested and real sync modes, ...)?

[clip]
Yes, sorry for the missing note, I fully agree with what you wrote and I
think we agree on the general signaling idea as well:

The "additional" progress signal I mentioned earlier should take care of
the progress part, we can also add a GetProgress() method if it seems
necessary. I hadn't yet designed this but it should look something like
this:

   signal StillUnnamedProgressSignal
     out UINT32 progress
     ARRAY of STRUCT (STRING source, UINT32 mode,
                      UINT32 prepare_current, UINT32 prepare_total,
                      UINT32 receive_current, UINT32 receive_total,
                      UINT32 send_current, UINT32 send_total)

In a way it's a waste to send all of that when on thing changes, but I
think it makes sense. The above does not include requested sync mode. Is
that needed? Anything else missing?

What a simple application might still want is an easier error indication
(Frederik already commented on this). What I was considering was
modifying SyncEnd like this:

   signal SyncEnd
     out UINT32 return
     ARRAY of STRUCT (STRING source, UINT32 return_value)

Does this make sense if we just forward the PEV_SYNCEND return values in
the source return values? I think it does because most clients could
then skip the synthesis progress signal alltogether and use the two
signals above...

  - Jussi
_______________________________________________
SyncEvolution mailing list
SyncEvolution@...
http://lists.syncevolution.org/listinfo/syncevolution

Gmane