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 <[email protected]> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
