Patrick Ohly wrote:
Unresolved issues:
* Do we want to implement the temporary configuration Patrick suggested?
Yes, but I've already said that ;-) Any other opinions?
I'm not really objecting... I guess the verbose logging example you gave
could be useful in the GTK+ client as well (with something like "sync-ui
-v").
Implementation details: should I add a "boolean temporary" to
SetConfig() or would you prefer a new method?
* anything else I may have forgotten?
Do we want to reserve the right to add more detailed information about
"processing" and "waiting", in other words, request that clients be able
to handle "running:waiting:foobar"? We don't have to use it, only
document it and write our clients accordingly.
I guess that does no harm.
Changes:
* GetConfigs: add string params for web url, icon uri and description
and boolean consumerready. Description is new compared to existing
api.
I assume this is to simplify the application startup. Clients could get
this by requesting detailed configuration information, right?
The drawback is that the API becomes very much tailored towards HTTP
servers. Any kind of additional information that we might need in the
future (Bluetooth device identifier, category of such a device, ...)
will require changes to the API.
Requiring that clients read the configs to get this information doesn't
suffer from this problem, because the hash is extensible. Do we really
need this?
No, it is not required. But the reason isn't just simplifying: I was
trying to minimize D-Bus roundtrips and transferred data size in
situations where the user is potentially actively waiting (like when
clicking on "Change sync service"). However, it is possible that I am
optimizing prematurely...
At least in the GTK client case the next best thing would actually be to
include the whole configuration for all servers in GetConfigs() -- I
have almost no use for just names -- but this would mean such a horrible
signature "a(sa{sa{ss}})" that I really don't want to implement it.
* SessionEnd renamed to SessionChanged (with boolean started)
* Removed Ready signal altogether (see below)
* StatusChanged and GetStatus: I tried to take the latest discussion in
to consideration and modified status values:
"not-ready": no 'lock' yet (better name suggestions?)
"queued"? But that might be to implementation specific.
I think "queuing" will work, it's better than "not-ready" anyway.
- Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
