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

[Dario Freddi]

On Saturday 01 May 2010 16:19:10 Dario Freddi wrote:
> Hello,
> 
> I managed to implement a preliminary version of StreamTubes. There's still
> a critical problem in the accept phase I cannot get over and I'd like you
> to take a look as well. But one thing at a time.

Quick update: I switched using Unix sockets in IncomingTubeChannel while the 
problem gets settled, and everything is working nicely :) I made the sockets 
exchange some random text messages and printing them to stdout. Also, to 
demonstrate that everything is working, the sender is using a standard 
QTcpServer with default listening arguments, while the receiver is using, as 
already said, a unix socket.

> 
> The code is in my private git repo (
> http://git.collabora.co.uk/?p=user/drf/telepathy-
> qt4.git;a=shortlog;h=refs/heads/high-level-tubes ), branch
> high-level-tubes. It's rebased upon the CMake branch, given that I suck at
> autotools and the cmake branch will be eventually merged before my changes
> get in. It features the new stream tube classes, and an example to let you
> test.
> 
> The problems:
> 
>  - I couldn't manage to demarshall the variant returned by
> StreamTube.Accept into a SocketAddress* struct. After some debugging and
> stuff, I'm completely clueless about the problem. Demarshalling the
> variant I managed to get the address literal as a QString, but not the
> port. The funny and problematic thing is that the very same thing happens
> in FileTransfer channel (in which I also fixed a bug which lead to a
> crash, patch upcoming), where the AcceptFile method should return the same
> struct.
> 
>  - I bundled all the features into FeatureCore.
> 
>  - When accepting the tube, at the moment I'm not giving the user a choice
> for the socket type. Any hints on how to do that in the API? I'd rather
> not expose the bare socket type.
> 
> That should be all for now.
> 
> On Wednesday 28 April 2010 19:42:14 Olli Salli wrote:
> > On Tue, Apr 27, 2010 at 10:44 PM, Dario Freddi <drf54321 at gmail.com> wrote:
> > > 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).
> > 
> > Sorry, I was totally talking crap here :( In reality, offering a
> > stream tube is equivalent to starting to listen on a socket and
> > "advertising" "I'm listening right here", not connecting. You seem to
> > be well aware of this though, hope I didn't confuse you too much.
> > Still, I wouldn't like Offer to take QIODevices, as a generic IO
> > device (think a file or somesuch) can't be exported, and it's actually
> > QTcpServer and QLocalServer which don't derive from QIODevice that
> > correspond to listening sockets. You could offer QTcpServer and
> > QLocalServer taking overloads though. It's easy to extract the address
> > from those. Still, you need the bare address version too, as the
> > socket isn't both a qt socket AND in the same process in all cases.
> > 
> > >> 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);
> > 
> > You don't need (actually even can't have) it returning a
> > PendingIODevice since, yeah, it's exporting a socket existing
> > somewhere in an address space the CM can see, NOT creating a new
> > socket (except implicitly by the CM when someone accepts in the other
> > end of the tube).
> > 
> > > 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.
> > 
> > QHostAddress is excellent for exporting TCP sockets, however we should
> > also expose unix sockets as supported by the spec. In addition to the
> > possible aforementioned QLocalServer taking overload this could be
> > simply an overload taking a const QString &socketName instead of the
> > QHostAddress. QString supports embedded NUL bytes so the abstract
> > socket case would be supported too.
> > 
> > >> 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.
> > 
> > The socket used in FT is just a temporary socket created exclusively
> > for transferring the file in question between the CM and the client,
> > enabling its type and access control to be "negotiated" by the client
> > and CM freely. TpQt4 FT uses IPv4 as the address type because the spec
> > requires all CMs to support it. For FT, Localhost access control is
> > sufficient for most cases, since the client and CM are running on the
> > same session bus, which usually means they're running on the same host
> > too.
> > 
> > For stream tubes however, the socket to export can be arbitrary
> > depending on the server application, and it's not necessarily
> > exclusively created to be exported over a Tube. It doesn't even have
> > to be on the same host, actually... So you do need to support
> > specifying the access control, but for most use cases Localhost should
> > be alright so it'd make sense to have it as a default parameter. One
> > thing buggering me is that the new stream tube D-Bus API doesn't
> > actually seem to have a way to provide the address for Port type
> > access control (old tubes api had a "access control parameter" variant
> > for this purpose) - so we really can't sensibly support anything other
> > than Localhost required or not and Credentials required or not.
> > 
> > So I think we're down to at least two overloads (one taking a
> > QHostAddress and the other taking a QString), possibly four
> > (additional ones taking QTcpServer and QLocalServer). Every method
> > should include an accessControl = Localhost parameter, and none should
> > return a IO device. Does this sound sensible this time around? ;)

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

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/20100501/87c9032b/attachment-0001.pgp>