http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #10 from pohly <[email protected]> 2009-09-17 01:22:05 --- (In reply to comment #9) > It should works. But the semantics is not quite clear: > For http transports, it actually doesn't has a connect phase visible to user, > so after creating a Http Transport, you can't say it is connected, isn't it? A transport without a concept of "stable connection" simply doesn't implement these calls. > And you probably need another syncAddress parameter in createTransport so that > it knows which peer to connect to. How do you solve this at the moment with outgoing OBEX? Where does the connection information come from? To some extend, extending createTransport() will be inevitable. Otherwise the client won't know whether it should create an HTTP or an OBEX transport. Some more thoughts about disconnect(): the current call sequence is create+(send+wait+getreply)*+delete. Getting a message without a prior send is not supported. cancel can be used to stop an active message send. In the D-Bus Connection glue code the initial message is received via some other means, then the core engine uses the TransportAgent to send either the initial SyncML message (acting as client) or the reply to a SyncML message (acting as server in a client-initiated session). In the later case, the normal call sequence is create+(send+wait+getreply)*+send+disconnect+delete. Because there is no final reply, the sender must check whether the connection was properly closed. The SyncML standard expects servers to not close the session (and update their anchors) unless the connection was closed successfully, which is the only indication available for "last message delivered". For us that means that "disconnect()" can be a long-running operation (last message might still get transmitted) that we may want to abort. I therefore suggest the following API change for TransportAgent: diff --git a/src/core/TransportAgent.h b/src/core/TransportAgent.h index 3636bed..3780ae9 100644 --- a/src/core/TransportAgent.h +++ b/src/core/TransportAgent.h @@ -32,7 +32,9 @@ namespace SyncEvolution { * - set parameters for next message * - start message send * - optional: cancel transmission - * - wait for completion and reply + * - wait for completion and the optional reply + * - close + * - wait for completion of the shutdown * * Data to be sent is owned by caller. Data received as reply is * allocated and owned by agent. Errors are reported via @@ -81,6 +83,17 @@ class TransportAgent virtual void setUserAgent(const std::string &agent) = 0; /** + * Requests an normal shutdown of the transport. This can take a + * while, for example if communication is still pending. + * Therefore wait() has to be called to ensure that the + * shutdown is complete and that no error occurred. + * + * Simply deleting the transport is an *unnormal* shutdown that + * does not communicate with the peer. + */ + virtual void shutdown() = 0; + + /** * start sending message * * Memory must remain valid until reply is received or @@ -101,13 +114,12 @@ class TransportAgent enum Status { /** - * message is being sent or reply received, - * check again with wait() + * operation is on-going, check again with wait() */ ACTIVE, /** * received and buffered complete reply, - * get acces to it with getReponse() + * get access to it with getReponse() */ GOT_REPLY, /** @@ -120,6 +132,10 @@ class TransportAgent */ FAILED, /** + * transport was closed normally without error + */ + CLOSED, + /** * transport timeout */ TIME_OUT, @@ -130,11 +146,15 @@ class TransportAgent }; /** - * wait for reply + * Wait for completion of an operation initiated earlier. + * The operation can be a send with optional reply or + * a close request. + * + * Returns immediately if no operations is pending. * - * Returns immediately if no transmission is pending. + * @param noReply true if no reply is required for a running send */ - virtual Status wait() = 0; + virtual Status wait(bool noReply = false) = 0; /** * The callback is called every interval seconds, with udata as the last -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
