http://bugzilla.moblin.org/show_bug.cgi?id=5188





--- Comment #8 from pohly <[email protected]>  2009-09-16 09:25:07 ---
(In reply to comment #2)
> > Changes: 
> > Add connect/disconnect in TransportAgent interface, though existing http
> > transports do not explicitly need the connect/disconnect operation but obex
> > needs this and I think it is better to put them at the transport interface
> > layer.
> 
> Ack.

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

Reply via email to