<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'Liberation Sans'; font-size:8pt; font-weight:400; font-style:normal;"> On Wednesday 28 April 2010 19:42:14 you wrote: > On Tue, Apr 27, 2010 at 10:44 PM, Dario Freddi <drf54321@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@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. Ok, now everything is clear :) > > >> 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). Of course: the PendingIODevice part should apply only to accept() (where I suppose I'll need to expose the socket access control as well). Also, any ideas on how to wrap the access_control_param variant (which still exists)? Up to now it is only used for IP sockets, and it should carry an IP address+port: the obvious solution is to throw in a QHostAddress, but I fear subsequent changes to the spec might actually throw in some other control parameters. Any thoughts on that? I think the best idea would actually be throwing in a QHostAddress, and eventually adding overloads subsequently. > > > 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) There still is (see my comment above): when accepting, you have to pass an access control parameter where you can specify an address+port. This is just done in the accept phase, though. > - 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? ;) It is :) What about: PendingOperation *offerTube(const QHostAddress &address, const QVariantMap &parameters, SocketAccessControl accessControl = SocketAccessControlLocalhost); PendingOperation *offerTube(const QString &socketAddress, const QVariantMap &parameters, SocketAccessControl accessControl = SocketAccessControlLocalhost); PendingOperation *offerTube(QTcpServer *server, const QVariantMap &parameters, SocketAccessControl accessControl = SocketAccessControlLocalhost); PendingOperation *offerTube(QLocalServer *server, const QVariantMap &parameters, SocketAccessControl accessControl = SocketAccessControlLocalhost); <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0; font-family:'liberation sans'; font-size:medium; color:#181818;"> And: <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0; font-family:'liberation sans'; font-size:medium; color:#181818;"> PendingIODevice *acceptTube(SocketAccessControl accessControl = SocketAccessControlLocalhost, const QHostAddress &address = QHostAddress()); <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0; font-family:'monospace'; font-size:medium; color:#181818;"> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0; font-family:'monospace'; font-size:medium; color:#181818;"> -- ------------------- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B</body></html>