http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #9 from Chen Congwu <[email protected]> 2009-09-16 18:19:46 --- (In reply to comment #8) 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? And you probably need another syncAddress parameter in createTransport so that it knows which peer to connect to. > (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. -- 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
