On Sat, Apr 24, 2010 at 3:55 PM, Dario Freddi <drf54...@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 _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy