On Mon, 2010-06-28 at 22:40 +0100, Frederik Elwert wrote:
> Am Montag, den 28.06.2010, 14:42 +0200 schrieb Patrick Ohly:
> > On Fr, 2010-06-18 at 09:14 +0100, Patrick Ohly wrote:
> > > I'll start filing issues with API proposals.
> >
> > Below a summary of the proposed enhancements. Does that sound right?
>
> Looks all right, thanks for picking up my proposals!
Thanks for making them! An API (only?!) becomes better once different
people try to use it... and provide feedbacks.
> > Do
> > we need additional flags for starting a session, beyond the "not for
> > sync"?
>
> Hm, I couldn’t find the flags defined for StartSessionWithFlags.
I copied the old "StartSession" method instead of the new one. Here it
is:
<method name="StartSessionWithFlags">
<doc:doc><doc:description>
Start a session. The object is created instantly but will not be
ready for method calls until status changes from "queueing" to "idle".
The Detach() method can be called before that. Additional flags,
identified by strings, can be passed to control the session creation.
They can be retrieved with Session.GetFlags(). The following flags are
currently defined:
<doc:list>
<doc:item><doc:term>no-sync</doc:term><doc:definition>session will
not be used for running a synchronization</doc:definition></doc:item>
</doc:list>
</doc:description></doc:doc>
<arg type="s" name="config" direction="in">
<doc:doc><doc:summary>configuration name</doc:summary></doc:doc>
</arg>
<arg type="a{s}" name="flags" direction="in">
<doc:doc><doc:summary>optional flags</doc:summary></doc:doc>
</arg>
<arg type="o" name="session" direction="out">
<doc:doc><doc:summary>session D-Bus object path</doc:summary></doc:doc>
</arg>
</method>
> Originally, I thought this could also be used for starting sync
> sessions. As I discussed earlier with Jussi (and if I understood
> everything correctly), there is an inherent race condition in the way
> sync sessions are created, because one has to request the session, then
> connect to the SessionChanged signal and launch the sync once the
> SessionChanged signal comes in (which might be before the signal was
> connected).
>
> So I thought one could work around this by calling a session with a
> "meant for sync" flag, but then a client would also have to know that a
> particular session was requested by itself, not by another client.
>
> So this was probably a bad idea, and it is enough to know that a session
> was not meant for syncing, as proposed. Sorry for thinking aloud, I just
> thought I might have overlooked something that someone else can see
> clearer.
I think you covered this well.
--
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
