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

[Dario Freddi]

On Tuesday 27 April 2010 21:37:59 Dario Freddi wrote:
> 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.
> > 
> > [snip]
> > 
> > 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).
> 
> As suggested, I changed the offer function in OutgoingStreamTubeChannel to:
> 
> PendingIODevice *offerTube(const QString &name, const QHostAddress
> &address, const QVariantMap &parameters);

Of course I meant:

PendingIODevice *offerTube(const QHostAddress &address, const QVariantMap 
&parameters);

And in Account:

PendingChannelRequest *createStreamTube(
            const ContactPtr &contact,
            const QString &serviceName,
            const QDateTime &userActionTime = QDateTime::currentDateTime(),
            const QString &preferredHandler = QString());

> 
> QHostAddress should already nicely encapsulate the needed logic for
> address_type+address, I would appreciate if one of you could confirm that.
> 
> I am wondering if I should also expose socket_access_control: in case it's
> not needed, what's a sensible default? I see in FT Localhost is always
> used, but I'm wondering if there are some use cases I'm not considering
> here.
> 
> > > 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

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

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/d35f48b9/attachment.pgp>