On Sa, 2011-12-10 at 13:49 +0100, Patrick Ohly wrote:
On Fr, 2011-12-09 at 18:43 +0000, Brian wrote:
> Patrick Ohly <patrick.ohly@...> writes:
> > On Fr, 2011-12-09 at 17:10 +0000, Brian wrote:
> > > Patrick Ohly <patrick.ohly@...> writes:
> > > but they also leave the notification
> > > icon live tempting me to distraction to check it...
> >
> > True.
> >
> > > I'd be happy to hand edit one of the config(ini) files...
> > >
> > > I only have one sync peer, so I'm not really qualified to answer per
> peer/global.
>
> > If the user wants different settings for different peers, the setting
> > has to be per peer.
> >
> > If the user wants the same setting for all peers, including those not
> > configured yet, and wants to turn them on and off for all peers at once,
> > then it has to be global.
> >
> > I personally expect the second case to be more likely. But what do I
> > know... user preferences are notoriously hard to predict
> >
>
> Agreed that user prefs are impossible to predict. If it's not too
> much coding, many hierarchical config frameworks allow a global setting
> which can be over-ridden by a per-peer setting.
The config files are hierarchical, but the hierarchy is not exposed in
the APIs: for example, a GUI can only set "loglevel", but not "global
loglevel".
It would be a useful extension. I need to think a bit about how to do
that.
How about this...
First, the current definition of config property (from the 1.2.1 man
page):
Sync and source configs contain configuration properties. Each property is a
name/value pair. Sync
properties are used in sync configs, source properties in source configs. The names
were chosen so
that they are unique, i.e., no sync property has the same name as a source property.
A property can be unshared (has separate values for each peer, therefore
sometimes also called
per-peer; for example the uri property which defines the remote database), shared
(same value for
all peers; for example the database property for selecting the local database) or
global (exactly
one value).
Let's extend that:
In cases where it makes sense (for example, the logging level), the property value
can be set at all
of the different levels. The most specific value then will be used (per-peer
overrides shared, shared
overrides global).
The name of a property without any specific prefix refers to the value at its most
specific
level. The "global", "shared", resp. "unshared"
prefixes select a certain level. For example:
globalLogLevel = 4, sharedLogLevel = 3 and logLevel = 2 result in a logging level of
2 for
the peer. "unsharedLogLevel" could have been used instead of
"logLevel".
The command line would be extended to list at which levels a property
can be set and what values it has where:
$ syncevolution --sync-property ?
[...]
loglevel (0, unshared, global) <=== "global" is
new
level of detail for log messages:
- 0 (or unset) = INFO messages without log file, DEBUG with log file
- 1 = only ERROR messages
- 2 = also INFO messages
- 3 = also DEBUG messages
3 = increasing amounts of debug messages for developers
[...]
remoteDeviceId (no default, unshared)
SyncML ID of our peer, empty if unknown; must be set only when
the peer is a SyncML client contacting us via HTTP.
Clients contacting us via OBEX/Bluetooth can be identified
either via this remoteDeviceId property or by their MAC
address, if that was set in the syncURL property.
[...]
All source properties would remain as they are. I don't see a need to
change any of them. The following sync properties would become
multi-level:
logdir (no default, shared, global)
loglevel (0, unshared, shared, global)
printChanges (TRUE, unshared, shared, global)
dumpData (TRUE, unshared, shared, global)
maxlogdirs (10, shared, global)
useProxy (FALSE, unshared, shared, global)
proxyHost (no default, unshared, shared, global)
proxyUsername (no default, unshared, shared, global)
proxyPassword (no default, unshared, shared, global)
SSLServerCertificates
(/etc/ssl/certs/ca-certificates.crt:/etc/pki/tls/certs/ca-bundle.crt:/usr/share/ssl/certs/ca-bundle.crt,
unshared, global)
Instead of blindly making all properties configurable at all levels, I
tried to find those where there are valid use cases. For example, I left
the auto sync settings per-peer only because the selection of which
transport to do auto sync on is peer-specific. The timing values might
be shared, but even that is uncertain.
Printing a config would show all levels like this:
# level of detail for log messages:
# - 0 (or unset) = INFO messages without log file, DEBUG with
log file
# - 1 = only ERROR messages
# - 2 = also INFO messages
# - 3 = also DEBUG messages
# > 3 = increasing amounts of debug messages for developers
loglevel = 4
# sharedLoglevel =
# globalLoglevel =
Or like this, when set only at the outer level:
# level of detail for log messages:
# - 0 (or unset) = INFO messages without log file, DEBUG with
log file
# - 1 = only ERROR messages
# - 2 = also INFO messages
# - 3 = also DEBUG messages
# > 3 = increasing amounts of debug messages for developers
# loglevel =
# sharedLoglevel =
globalLoglevel = 4
Setting it would be done like this:
$ syncevolution --configure loglevel= globalLogLevel=4 <config>
It is impossible to distinguish between setting loglevel to an empty
value (and thus the default) and unsetting it (which in this case means
falling back to the global value).
The current implementation sets the empty value. It is not possible to
unset a property. I propose to change the interpretation of "empty
value" to "unset the property".
That covers the command line. In the D-Bus API the additional values
show up as if they were new properties. Under the current rules a D-Bus
client already must preserve them. Because the traditional names are
defined so that they override the other values, a client which only
knows how to set the traditional values will still do the right thing -
almost.
Setting them has the desired effect, but when reading the current value
it is no longer enough to look at just "loglevel". If that is unset, the
client also has to check "sharedLoglevel" and "global"Loglevel".
Having
said that, the GTK sync-UI doesn't do anything like that and thus
doesn't have to be adapted.
> > > If it's straightforward, I would think that
separating "info" versus "error"
> > > would make a lot of sense.
> >
> > There could be a "notify level" similar to the current log level: 0
=
> > everything, 1 = only errors, 2 = errors and info messages.
>
> What's the difference between 0 and 2? I would think that 0 = nothing?
Right, 0 was meant as "show nothing".
Would another distinction between "info message about sync without
changes" and "info message about sync with changes" be useful?
Yes. With that in mind the full definition would be:
notifyLevel (3, unshared, shared, global):
Level of detail for desktop notifications. Currently such
notifications are generated only for automatically started
sync sessions.
0 - suppress all notifications
1 - show only errors
2 - show information about changes and errors (same as level 3 at the moment)
3 - show all notifications, including starting a sync
Does this all make sense so far?
--
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.