ip4-address buddy property - still needed?

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We still have one set of OLPC-specific patches to Salut (the link-local
collaboration backend) that has been rejected upstream, which is the one
that adds support for the deprecated ip4-address buddy property. This was
used during a transitional period to enable simple TCP-based collaboration
for activities that didn't use Tubes; Sjoerd is reluctant to keep this
patch set, because it's meant to have gone away by now!

Is anyone still using this property? If not, can we kill it? It was
added in Trial-2, and it was meant to be gone by Trial-3 but was left in
just in case, so it really ought to disappear. When it does, we can
delete some code from Salut and Presence Service.

Places it's exposed in the APIs, which I propose to get rid of:

PS D-Bus API: Buddy.GetProperties() returns a dict that contains
    "ip4-address": "10.0.0.1" (or whatever), and Buddy.PropertyChanged
    signal includes a dict that can contain the same

sugar.presence: Buddy has a GLib property "ip4-address" (aka
    buddy.props.ip4_address) and can emit it in its property-changed signal

The Read activity appears to be the only thing in my jhbuild that uses
ip4-address (#4297). It should be ported to either stream tubes (when they're
ready in Salut, which should be this or next week) or D-Bus tubes (now).

Gabble already supports stream tubes, so stream-tube support can be
implemented on a branch and tested against Gabble. Porting from plain TCP
to stream tubes should be very straightforward; I hope to produce a
proof-of-concept patch for Read later today.

    Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFHIF7HWSc8zVUw7HYRAvp6AJ9G/Xiw27pPPMm0g02vhXzRhzUxqwCfW27Z
nh1B/wqe7GD/xf/YaOPVaw8=
=42L7
-----END PGP SIGNATURE-----