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
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
