[Telepathy] API Draft for high level tubes in tp-qt4

[Olli Salli]

On Sat, Apr 24, 2010 at 3:55 PM, Dario Freddi <drf54321 at gmail.com> wrote:
> Hello,
>
> please find attached a new version of tp-qt4 high level tubes.
>
> This time they're really high level - I tried keeping the API (and parameters
> as well) as similar as possible to tp-qt4 file transfers - it also features
> the same mean of creation by using TubeChannelCreationProperties.
>

The basic premise for FileTransferChannelCreationProperties's
existence is the large number of properties that can be specified when
requesting a FT channel, some of which are mandatory and some which
are not. For Tubes the only properties one can provide are mandatory,
and there is only one for each type (service for stream and service
name for d-bus tubes). As for the other attributes in your
CreationProperties classes, I think the parameters are best specified
at Offer time as happens at the TP level. Hence I think an additional
CreationProperties class just obscures and complicates Tube creation
needlessly.

The device attribute I'm not really getting - why would an app
requesting a tube have a relevant IO device already? Connecting
sockets to sockets when implementing a "tunneling" application? I
think this is cargo-cult from FT, where one provides the file to send
by providing a QIODevice - this is an abstraction for giving it an
existing "file" of any kind. However, the use case here is completely
different. One should consider setting up an outgoing stream tube
analogous to connecting a TCP socket from a client to a server for
communication. One should be able to easily replace the TCP connect
logic in a networked app by offering a d-bus tube with the remaining
app logic remaining the same (using a QIODevice for communication,
this time it being the tube instead of a QTcpSocket set up by the
application).

> My only concern is if it is possible to obtain all the needed properties from
> a QIODevice when offering/creating a StreamTube.
>

Taking the above into account, the only QIODevices relevant here
should be ones created by TpQt4 based on the info the CM provides it
with after Offer has returned - you shouldn't need to dig any
information from any user-provided io devices. One thing you do need,
though, is exposing the address family / access control parameters for
Offer.

> (The package does not include the new functions in Account, but they're
> obviously there)
>
> Please comment on this one - if you're happy enough, I'll start hacking on
> them straight away ;)
>
> On Monday 19 April 2010 19:57:40 Andre Moreira Magalhaes wrote:
>> On 18/04/10 10:09, Dario Freddi wrote:
>> > Hello all,
>> >
>> > as discussed with Andre on IRC, I drafted a small API for managing Tubes
>> > in tp-qt4 (see attachment). There's really nothing fancy here: it's a
>> > quite straightforward mapping of the spec to a Qt-like API, and it's
>> > mostly what tp- glib does as well.
>> >
>> > Still, I'd find it cool to provide a function returning a QAbstractSocket
>> > for StreamTubes and a QDBusConnection (or a DBusProxy) for DBusTubes to
>> > make it extremely easy to use the opened tube. I'd like some feedback on
>> > that though, since I don't know how much it would be feasible.
>>
>> I like the overall idea, but I would change some things as:
>> - ST and DT should be implemented similarly to FileTransfer channels
>> where we have Incoming/Outgoing channels depending on the requested
>> property of the channel.
>> - For ST you probably want to return a QIODevice on accept, or a
>> PendingIODevice (you name it) of some sort, so you can instantiate a Qt
>> Socket object (QLocal/Tcp/UdpSocket) depending on the type of the socket.
>>
>> You may want to check how FT is implemented in tp-qt4 and get some ideas
>> from there.
>>
>> BR
>> Andre
>
> --
> -------------------
>
> Dario Freddi
> KDE Developer
> GPG Key Signature: 511A9A3B
>



-- 

Br,
Olli Salli