On Mon, 2009-08-31 at 19:05 +0100, Frederik Elwert wrote:
> > > 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.
>
> Couldn’t the clients do the localisation stuff? If errors are presented
> as raw enum values, with documentation somewhere about the meaning of
> these values, clients could take care of the natural language version
> and translations.
This is already more or less how the Synthesis error codes work, but
sometimes it is hard to interpret them the right way. If we could
provide localized error messages, then this interpretation work wouldn't
have to be duplicated in all clients.
> > > Sync
> > > in ARRAY of STRING sources
> >
> > Instead of selecting sources in the Sync method, should we introduce the
> > concept of temporarily overriding sync properties? These changes can be
> > attached to the Session object. That way the sync mode can be changed
> > for just the next run without permanently changing the configs. Proposal
> > below.
>
> I’d like the Sync method to be as simple as possible. Maybe the CLI can
> be of conceptual help: A plain call without further arguments syncs all
> sources with the sync mode specified in the config (which might also be
> "none"). A call with --sync <mode> syncs all sources with mode <mode>
> (except for those with sync disabled in the config). The DBus API could
> go one step further and allow to sync several sources with different
> modes (which I think the CLI currently doesn’t support.
>
> So I think of something along the lines of the current API:
>
> Sync
> in DICT ( STRING source, INT mode )
>
> but with the following rules:
>
> * If the dict is empty, the default modes are used as specified in
> the config.
> * If the dict contains an empty string as key, this is used for
> all active sources, if not specified otherwise. So {'': 2} would
> force slow sync for all active sources.
> * Explicitly specified sources override the defaults, so
> * {'calendar': 2} would force slow sync for calendar, and
> sync all other sources as normal, while
> * {'': 0, 'calendar': 1} would sync only calendar in
> two-way mode.
>
> This would allow fine-grained control while making common tasks easy.
Setting sync modes in the Sync() method is a special case for a more
general problem (temporarily overriding the config). My thinking was
that we need a solution for that general problem (do we?) and then the
special case is no longer needed. But the special case is so common,
perhaps it really deserves special treatment?
> > > SetConfig
> > > in DICT (STRING source, DICT (STRING key, STRING value))
> > > UpdateConfig
> > > in DICT (STRING source, DICT (STRING key, STRING value))
> > >
> > > [NOTE: outer dictionary contains a dictionary for every source and
> > > one dictionary for server config]
>
> What is the difference between the two? Are they both needed?
My understanding is that SetConfig will remove all properties which are
not set anew, whereas UpdateConfig will update the properties which are
set and leave the rest alone.
UpdateConfig could be almost replaced by GetConfig+update properties
+SetConfig, except for on difference: SetConfig would also wipe out all
non-property content of the config (comments that the user might have
added).
I think both are needed, with UpdateConfig being used in almost all
cases.
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
