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

Tue Apr 27 09:43:25 PDT 2010

Hi Olli and thanks for replying,

On Tuesday 27 April 2010 18:30:03 Olli Salli wrote:
> 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.

You are right - I'll remove that specific bit.

> 
> 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.

I did not borrow it from FileTransfer - it is probably a misunderstanding in 
the Stream tube API. What I understood is that StreamTube exports an already 
existing socket, so to avoid specifying the socket type, access control, etc I 
thought about passing an existing socket from the application, exporting its 
address and setting up the property for the tube connection by introspecting 
the QIODevice.

> 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).

This makes way more sense. I'll update that part.

> 
> > 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.

For sure. I'll send a last update soon, thanks for the valuable input.

> 
> > (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

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20100427/94fba177/attachment.pgp>