On Fri, 2010-08-20 at 11:41 +0100, Graham Cobb wrote: > On Friday 20 August 2010 07:54:00 Patrick Ohly wrote: [...] > And it is working because we seem to have uncovered two design bugs > already. One already reported and the other not.
Which one wasn't reported? > > 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? Yes. The other part of the configuration for a sync session is the "sync profile". It references the "service profile" to get some settings (sync URL being one of them), but also adds the per-user settings (username/password). The "service profile" is stored in ~/.sync and thus per-user. > 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)? That's where I need Sateesh's help. I don't know whether the local URI is part of the service profile or the sync profile. The example and experiments show it as part of the service profile, but perhaps that is changing. There's no documentation yet that describes what goes where. > > 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? That works. msyncd has some very simple locking mechanism that prevents two different services from synchronizing the same data at the same time. > > > 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? There was no scheduler in MeeGo when Buteo was merged. I think it relied on a Maemo service before. Perhaps we'll get to that point again later. > 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)? Right now, the *only* interface to sync is via msyncd's D-Bus interface, so yes, there is one ;-) > > [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). Sync client allow it to be specified because it typically varies among services, as you said, but which service let's you configure multiple URIs? SyncEvolution and your custom Synthesis allow that, but I'm not aware of a consumer service supporting that. > 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? An URI identifies the database. Whoever starts a SyncML session needs to know the RemoteURI of its peer in advance, then tells the peer about its own corresponding LocalURI (roughly speaking; with Server Alerted Sync the situation is slightly different, but the problem itself remains). So on a device, the local URI is typically entirely under the control of the device. The remote URI however is defined by the service and must be configured correctly, otherwise syncs will fail. -- 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. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
