WIP branch, API isn't finished yet. Depends on TpChannelView from #29218.

Not actively being worked on, AFAICT, so back to NEW.

This branch should be rebased on top of master and be ported to have a TpDBusTubeChannel object instead.

I started working on this, not much so far but that's a start: http://cgit.collabora.com/git/user/cassidy/telepathy-glib/log/?h=dbus-tube-29271

I also started working on this a while ago. However I'm happy for you to take it over.

Yeah I saw, but your branch was pre TpChannel sub-class so it was easier for me to start fresh cargo culting TpStreamTubeChannel.

Aah, I have another one on my laptop I mustn't have pushed.

Guillaume's branch is already a good start. I think we should already merge that part since it's pretty-much straightforward (copied from TpStreamTubeChannel). It is just missing factory integration to be ready to merge IMO.

So needs a _tp_dbus_tube_channel_new_with_factroy() and use it in TpAutomaticClientFactory.

Added 3 commits on top of Guillaume's branch. Now TpDBusTubeChannel gets constructed by factory and is introspected.

Ok, that skeleton is now merged and hooked into the factory. Still missing useful _async methods though.

This would be really nice to have available to LibreOffice last week, so I'm looking at quickly polishing enough of this up to let them delete some handrolled code. :)

It looks like this stalled partly due to bug 41323.

Here is a branch based on Guillaume's branch with one commit amended, and re-Authored to me, and some other commits.

I've reviewed all of Guillaume's code and it either looks fine or I've fixed it.

I've omitted the top WIP patch from Guillaume's branch which deals with name owner tracking, which I presume is blocked on bug 41323. It's not needed for 1-1 tubes anyway.

And I dodged the question of how to support specifying LOCALHOST as the access control because, frankly, the only platform that needs it is Sugar.

Interested onlookers can find Guillaume's WIP patch at <http://cgit.collabora.com/git/user/wjt/telepathy-glib/log/?h=dbus-tube-29271>.

I'm going to have a crack at porting the LibreOffice tubes thing to this to verify that it works in practice.

Note that the example doesn't work the first time you run it due to 47760.

+      /* FIXME: this is pretty stupid but apparently unless you start and then
+       * stop the server before freeing it, it doesn't stop listening. Calling
+       * _start() twice is a no-op.
+      */

Sounds like a GDBusServer bug no? Did you report it?

+  /* FIXME: this isn't a particularly good error… it's just what comes out when
+   * the channel gets closed from under us, and there isn't really API on
+   * DBusTube to give a better error.
+   */

I think we should have some way to say if the receiver rejected the tube invitation. Open a spec bug?

"DBusTubeChannel: always use CREDENTIALS for now"
I agree. Specific system like Sugar can easily patch this and we can always use a tp_dbus_tube_channel_use_localhost_crendetial () later if we really need to.

Ideally I'd prefer have more examplary examples using GDBus's code generation but that will do for now.

(In reply to comment #12)
> I've omitted the top WIP patch from Guillaume's branch which deals with name
> owner tracking, which I presume is blocked on bug 41323. It's not needed for
> 1-1 tubes anyway.

Yeah it's block on it. Could you please open a new bug once this one if merged/closed?

Created attachment 59377 [details] [review]
An example of porting LibreOffice's tubes branch to this

I ported the feature/tubes2 branch of LibreOffice to use this branch to check that it works (attached). I was a little disappointed that it didn't save more code. The main reason, I think, is that the paths which call _offer_async() and _accept_async() are essentially identical but have to be duplicated.

(In reply to comment #14)
> +      /* FIXME: this is pretty stupid but apparently unless you start and then
> +       * stop the server before freeing it, it doesn't stop listening. Calling
> +       * _start() twice is a no-op.
> +      */
> 
> Sounds like a GDBusServer bug no? Did you report it?

I have now. https://bugzilla.gnome.org/show_bug.cgi?id=673372

> +  /* FIXME: this isn't a particularly good error… it's just what comes out
> when
> +   * the channel gets closed from under us, and there isn't really API on
> +   * DBusTube to give a better error.
> +   */
> 
> I think we should have some way to say if the receiver rejected the tube
> invitation. Open a spec bug?

bug 48196.

Okay, I merged this with some doc fixes and bug references. Exciting. http://cgit.freedesktop.org/telepathy/telepathy-glib/commit/?id=dcab14f903605fc2f0c162e45b1c322966eb46c2

This'll be in 0.17.8 or 0.18.0 I guess! Hooray.

(Retitling for the tube participant API that's still missing.)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-glib/issues/37.