[Bug 29218] TpStreamTube - high level stream tube API

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29218

--- Comment #24 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-09-23 08:51:29 PDT ---
(In reply to comment #20)
> * Am I going to let telepathy-glib make the connection, or hand it over to
> someone else?
> 
> Vinagre has been adapted to Tubes, so it makes sense for it to get a GIOStream
> from Telepathy. A less well-adapted application might expect a GSocketAddress,
> but it'll never integrate very well like that; I think we'll basically only see
> this for a thin shim that invokes something with command-line arguments (e.g.
> an _http._tcp tube handler that runs "firefox http://127.0.0.1:4242/").

Yeah except that Vino/Vinagre are not using GIOStream yet and Wormux for
example will never use it even if we add good (optionnal) Telepathy
integration.
So I think it's important to keep this case in mind as it will probably be the
main case actually.

> * If I'm going to hand the connection over to someone else, what does it
> support connecting to, and how can we do access-control?
> 
> In practice, I think the answer will be (IPv4, Localhost).

IPv4 for now and hopefully IPv6 in some future.
I'm not sure for LocalHost. If I'm offering a tube, using Port totally makes
sense as it doesn't affect the "protocol" and allow us to identify incoming
connections.
Oth, as you can see in my tp-glib implementation, breaking the races is
actually far from being trivial. :\

I suspect the answer here "If you want to use a Muc Stream tube, then you have
to use GIOStream and use the 'simple' API to be able to identify connections".

> * Am I going to connect once, or repeatedly?
> 
> HTTP is pseudo-connectionless, so you have to give your HTTP library (or web
> browser) a host:port and go from there. However, if you're well-integrated
> enough to be using GIOStream, it seems unlikely that you're using a protocol
> that works like that (it'd be too painful for a start!)

Makes sense.

> I think we have two cases to deal with here:
> 
> Fully-integrated Telepathy app
> ------------------------------
> 
> * Call accept_[and_connect_]async() and get a GIOStream
> * Internally, pass around a data structure containing the GIOStream and the
> TpStreamTubeChannel
> * Use whatever socket type telepathy-glib wants (Unix if supported, else IPv4)
> with the best possible access-control

That's what I implemented currently. Does this API looks good to you?

> Handover to external process
> ----------------------------
> 
> * You need to know what socket types external processes can use, so nothing
> telepathy-glib can do will be good enough for you
> * Get the properties and call the Accept() tp_cli API yourself
> * You can handle multiple client connections, at your own risk

I still think we should have high level API for this case. If only because
tp_cli_* is not accessible in other language.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.