Re: [SyncEvolution] gtk ui status update
On Mon, 2009-11-16 at 20:47 +0000, Jussi Kukkonen wrote:
Sorry for the radio silence, I haven't been very productive in
the last
month...
Glad to have you back ;-)
Comments on the api after actually implementing a client: So far
it's
been quite a bit more work than the old one.
This is not entirely surprising. After all, in the previous API you had
the backend completely for yourself and everything was designed for use
in the sync-UI. Now you have to potentially share the server with other
users, both frontends and other activities going on in the background.
My apology for making your life harder; I hope it is worthwhile :-/
Some open questions:
* Can I find out if a source is supported on local machine without a
Session? This would be useful so I could show the UI even if another
Session is running.
Not at the moment, but I think it could be added.
* Server.GetSessions() is not implemented: was this on purpose?
No. Please file an issue, blocking 7210 and assign it to Yongsheng.
Yongsheng, I hope you have time for this right now, otherwise I'll do it
later this week.
* If it gets implemented, can I trust that the first one is
currently
active?
We haven't defined an order in the API spec. We could add this:
"sessions are returned in the order in which they will run, running ones
first".
I don't think we should guarantee that sessions really are active. What
if some of them wait for some external event, like network becoming
available? We don't have this right now, but it might get added.
* syncing seems to make the session inactive (after the sync
finishes),
is this as designed?
Yes. The intention was that other, queued sessions can run immediately
after the syncing one is done, without having to wait for a client to
react. Is this a problem?
* I can't seem to get StatusChanged from Session B in this
case:
- session A starts syncing
- session B starts
- session A stops syncing, detaches
I expected to get StatusChanged "idle" for B but I don't
I need to check this. The problem is that my test case for this depends
on glib mainloop bindings in a python-gobject release that is so recent
that Debian Stable (on my laptop) doesn't have it.
--
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.