On Wed, 2009-09-02 at 16:02 +0100, Jussi Kukkonen wrote:
> 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?
Let's use another boolean. SetConfig(true, false, ...) is not
particularly readable, but so be it.
> > 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...
I'd prefer to implement the simpler API first and then optimize it after
having tried out how badly the round-trips affect GUI startup time on a
Netbook. 1ms was mentioned as a ballpark figure for a single round-trip;
that should allow us some back-and-forth before it hurts.
Ack on the other changes ("running:waiting:foobar", "queuing").
--
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
