[MeeGo-dev] Buteo / data synchronization in MeeGo: hello world!

[Sateesh Kavuri]

Sorry for the late reply! Was away from work last two days

On Friday 20 August 2010 04:11 PM, ext Graham Cobb wrote:
> On Friday 20 August 2010 07:54:00 Patrick Ohly wrote:
>    
>> This thread is in danger of being off-topic for this list. I'll try to
>> keep it focused on the  Buteo design and source code; hopefully that'll
>> keep it relevant for this list, otherwise we should move the thread.
>>      
> Thanks for your response, Patrick.
>
> I certainly hope it is on-topic for this list (and I note your other email
> asking Dawn for clarification) as Buteo is a MeeGo component.  Note that I am
> not interested (at the moment) in either what features are exposed to the
> users by the UI, nor in the API for adding and controlling sync.  I am
> interested in the design decisions of the sync service itself and the
> requirements they are based on and, in the absence of documents, I am using
> use-cases to try to clarify my questions about the design.
>
> And it is working because we seem to have uncovered two design bugs already.
> One already reported and the other not.
>
> I am sure none of the other meego- lists is more relevant for this discussion.
> If this is not the right list then there needs to be a Buteo-specific list
> (with Buteo viewed as an upstream project that MeeGo is using instead of as
> part of MeeGo).  That would also avoid the need for this cumbersome CC: list.
>
>    
>> Note that this requirements for service profiles in /etc is by design.
>> It has the side effect that the user cannot define a custom sync service
>> in the GUI (see http://bugs.meego.com/show_bug.cgi?id=4941).
>>      
> I see this as a bug and will work the issue in bugzilla.
>
> One additional question, though, does the design allow for multiple user sync
> profiles which use the same service profile?  For example, having installed
> the ScheduleWorld service profile, can the user profiles specify multiple
> local calendars to synchronise with different remote ScheduleWorld calendars
> (with different usernames)?
>
>    
Yes, the design does allow (and is based on the concept) of multiple 
profiles
and each profile having the ability to support multiple Calendars, multiple
accounts etc. The high level requirements are listed here: 
http://wiki.meego.com/Buteo/Framework#Requirements

>> There is nothing that prevents defining multiple calendar entries under
>> different names in a service profile, but again, this is nothing that
>> the user can change.
>>      
> Putting aside the user access for the moment, is there anything to stop the
> same local calendar instance appearing in multiple service profiles?  For
> example, synchronising one local calendar against two remote calendars?
>    
A profile is composed of elements, like the name, target service 
identifier (BT address/URL/...),
the calendar used, etc. There is flexibility in the framework to support 
synchronizing
a local calendar to any number of remote calenders, but this is 
something that has
to be conceptualized in MeeGo and the framework can be used accordingly
>    
>>> 4) Each calendar can synchronise as a "master" (not a device) with
>>> other "devices" (e.g. other phones or a kitchen clock or something).
>>> This is particularly important for netbook mode but it should also be
>>> available on handsets.
>>>        
>> Note that there are currently issues with data loss when doing two-way
>> sync, primarily in this mode, but also when syncing as device with a
>> less capable master:
>> http://bugs.meego.com/show_bug.cgi?id=4897
>>      
> Thanks, that is a big part of what makes sync complicated and a big part of
> what Synthesis and OpenSync do.  I will add myself to the CC: list to watch
> that bug.
>
>    
>>> 6) It should be possible to schedule syncs (the scheduling is a system
>>> issue, not a Buteo issue)
>>>        
>> msyncd is the core Buteo daemon, and it controls the schedule for
>> running syncs.
>>      
> Why is there a scheduler in a sync subsystem?  That seems to be a design bug.
> It should be using whatever the system provides as a scheduler (note: I am
> not talking about the UI -- it may well be relevant to present scheduling
> screens to the user as part of configuring sync).
>    
The scheduler for the sync subsystem is used to schedule synchronization
sessions. This is not a real scheduler beast, but basically maintains an 
alarm
inventory for all scheduled synchronizations. The user has the ability 
to set a
schedule (using UI or some other app using the framework API) and such
a schedule is stored by the engine. The particular sync session(s) is 
invoked
whenever the alarm kicks in (Note that the alarms are maintained using 
QTimer
mechanism.
> Is there an API (e.g. using dbus) to allow syncs to be initiated under control
> of some other scheduler (or, for that matter, some other component's UI)?
>    
Yes, it is possible. There is a dbus API as well as a client library API 
(just a wrapper
around dbus)
>    
>> [multiple calendars]
>>
>>      
>>>> [SK] This agreement is something that would be part of the protocol in
>>>> use. Apparently SyncML does not have this facility.
>>>>          
>> It does. uri=calendar/work and uri=calendar/personal can be used. The
>> only problem is that most existing services do not offer that.
>>      
> In my limited experience, most services seem to allow the URI to be specified
> (not least because of the different values expected by different devices).
> It isn't clear to me how the URI the remote side specifies in the SyncML
> request interacts with the URI values in the service profiles (or, more
> importantly, the values in the user's own sync profiles).  Can you explain a
> bit more how the LocalURI and RemoteURI are used?
>    
The RemoteURI is used to identify a database on the remote service, so a
service XML would have this information whenever the device in question
would like to initiate sync with the target service. Similarly, a 
LocalURI is published
to be used by other services when they would like to synchronize with 
the host device

> Graham
>    
Sateesh