[Syncevolution-issues] [Bug 5188] Outgoing obex connection for SyncEvolution

(In reply to comment #2) After running into the same situation with the D-Bus Connection interface I've come to a slightly different solution. First, connect() isn't really needed in the TransportAgent API, is it? Whoever creates a transport which needs such a call can call its own version of connect(), most likely using transport specific parameters. In other words, EvolutionSyncClient::createTransport() must return a transport which is already connected. Does that make sense? Second, I've defined the disconnect() call a bit differently: /** * Disconnect the transport. In contrast to cancel() below, this * indicates a normal shutdown of the transport. Simply deleting * it is considered an *unnormal* shutdown. */ virtual void disconnect() = 0; The difference between "normal shutdown" and "abnormal shutdown" when deleting directly is one reason why the call is necessary. The other is shutting down the connection some time before deleting it. A minor difference is that I decided to make disconnect() pure virtual, to force implementors to think about the call. The approach above is similar to creating a file in Python with various different create methods and a single close() method inside the file handle. I haven't committed this yet. It'll be in the "dbus-api" branch soon. Please let me know whether this also works for OBEX.