Re: ip4-address buddy property - still needed?
The feature, although not usable by the activities, it has other benefits. By observing the buddy list, you acquire instant information of the network connection go the users: when connected to channel 1 for example: 169.254.x.x address are in link-local 172.18.x.x are connected to schoolserver when connected to a jabber server: 169.254.x.x are connected through an MPP 18x.x.x are media lab 172.18.x.x are connected to schoolserver in olpc etc It is information continuously used in network testing, also useful from the users prespective: 1. in the case of connecting to multiple jabber servers, the user should be able to tell which XO in the neighbout view belongs to the same school 2. get the geopraphical location of another user In future versions of the neighbor view, or through other activities, the user should be able to filter for specific XOs according to location, or school(in the case he's connected to many servers). Two children in the same school should be able to recognize each other even if they are connected through a jabber server, other then the one in the school. It can also be useful for locating an XO in case of theft. I have also added a ticket(4405) for adding the public id in the buddy list properties. It is a small part of data(both IPs, private and public), which can be harmfully incorporated in the telepathy services. Please let me know if you agree, yani On 10/25/07, Jim Gettys [EMAIL PROTECTED] wrote: It seems, from your discussion like unless someone grumbles today, this should be removed immediately. And it removed within a week, even if someone grumbles... - Jim On Thu, 2007-10-25 at 10:15 +0100, Simon McVittie wrote: -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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On Nov 2, 2007, at 9:17 PM, Marco Pesenti Gritti wrote: Also I think integrating and properly supporting Pascal's log collector would go a long way in facilitating testing. Working on this bit. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On Fri, Oct 26, 2007 at 01:18:17PM -0400, Michail Bletsas wrote: At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. Anyway The big issue for me is that once the ipv4 information is in a shipped release we're somewhat doomed to keep it in... But what your actually saying is that you want a graphical way to collect this information, not specifically that it has to be part of the information salut (or even telepathy) has.. Turning avahi-discover into an XO app, should be reasonably straight forward (it's a trivial application, using pygtk already). And it has all the information you need (and some more). Would that be a solution for your problem ? Sjoerd -- My geometry teacher was sometimes acute, and sometimes obtuse, but always, always, he was right. [That's an interesting angle. I wonder if there are any parallels?] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On 10/30/07, Sjoerd Simons [EMAIL PROTECTED] wrote: On Fri, Oct 26, 2007 at 01:18:17PM -0400, Michail Bletsas wrote: At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. It's on the build actually but it's not working. It will be replaced shortly by a couple of activities. (Log and Analyze). Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. In analyze-acivity, I wrote a python file called netdevice.py which return the network devices, IP, Netmask and MAC Address... Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. Yeah, we're killing the developer console... cheers. Ed.- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
Please check: http://wiki.laptop.org/go/Developer_Environment On 10/30/07, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On 10/30/07, Sjoerd Simons [EMAIL PROTECTED] wrote: On Fri, Oct 26, 2007 at 01:18:17PM -0400, Michail Bletsas wrote: At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. It's on the build actually but it's not working. It will be replaced shortly by a couple of activities. (Log and Analyze). Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
While I welcome the new activities and think it is great to integrate them into sugar, can we reconsider completely doing away with the dev console? It is /very/ useful to have the console open on an xo while the activity you are debugging is running behind it. Can't you have both the old console and the new activities? On 10/30/07, Eduardo Silva [EMAIL PROTECTED] wrote: Please check: http://wiki.laptop.org/go/Developer_Environment On 10/30/07, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On 10/30/07, Sjoerd Simons [EMAIL PROTECTED] wrote: On Fri, Oct 26, 2007 at 01:18:17PM -0400, Michail Bletsas wrote: At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. It's on the build actually but it's not working. It will be replaced shortly by a couple of activities. (Log and Analyze). Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On 10/30/07, Erik Blankinship [EMAIL PROTECTED] wrote: While I welcome the new activities and think it is great to integrate them into sugar, can we reconsider completely doing away with the dev console? It is /very/ useful to have the console open on an xo while the activity you are debugging is running behind it. Can't you have both the old console and the new activities? Once the new activities are in, please give them a try a report the usability issues you are finding with them on a ticket. We can rediscuss this with Eben and see how can we best solve the problems. Thanks, Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On Fri, Oct 26, 2007 at 12:20:01AM -0400, Giannis Galanis wrote: The feature, although not usable by the activities, it has other benefits. By observing the buddy list, you acquire instant information of the network connection go the users: when connected to channel 1 for example: 169.254.x.x address are in link-local 172.18.x.x are connected to schoolserver when connected to a jabber server: 169.254.x.x are connected through an MPP 18x.x.x are media lab 172.18.x.x are connected to schoolserver in olpc etc It is information continuously used in network testing, For the link-local case you can just ask avahi for this information directly. For the jabber/server case, i'm unsure why your interested in how other nodes are connected to the jabber server in the first place. also useful from the users prespective: 1. in the case of connecting to multiple jabber servers, the user should be able to tell which XO in the neighbout view belongs to the same school Maybe this has changed. But afaik there will be one jabber server per school (on the school's server) and you can thus look at the users jid. 2. get the geopraphical location of another user A much better way for doing this would be to integrate some geoclue[0] information into telepathy. Instead of having each XO's trying to work out where others are by the small amount of information an ip reveals. In future versions of the neighbor view, or through other activities, the user should be able to filter for specific XOs according to location, or school(in the case he's connected to many servers). Two children in the same school should be able to recognize each other even if they are connected through a jabber server, other then the one in the school. An xo should always connect to the same jabber server afaik.. It can also be useful for locating an XO in case of theft. In the case of theft the jabber server the XO is connecting to always has the information of where a connection came from (or at least of the last nat hop and you can work from there). I don't see the point of pushing that info to all xo's. I have also added a ticket(4405) for adding the public id in the buddy list properties. It is a small part of data(both IPs, private and public), which can be harmfully incorporated in the telepathy services. I definately agree that having some information of where in the world your buddy's are is something very nice. I disagree that exposing ip addresses is the way to do it though. Sjoerd 0: http://www.freedesktop.org/wiki/Software/GeoClue -- Mediocrity finds safety in standardization. -- Frederick Crane ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 26 Oct 2007 at 00:20:01 -0400, Giannis Galanis wrote: The feature, although not usable by the activities, it has other benefits. By observing the buddy list, you acquire instant information of the network connection go the users: when connected to channel 1 for example: 169.254.x.x address are in link-local 172.18.x.x are connected to schoolserver Wouldn't it be better if the information that was exposed was the information you actually want, rather than a coincidental factoid from which you can guess it? I'm connected to the mesh vs I'm connected via school server foo.schools.laptop.org vs I'm connected to some other random access point. 1. in the case of connecting to multiple jabber servers, the user should be able to tell which XO in the neighbout view belongs to the same school Users should only need to connect to multiple Jabber servers if they want multiple distinct identities (e.g. I have a personal Jabber account and a work Jabber account). This seems an unlikely goal for OLPC. If two users on different Jabber servers want to communicate, the way that is done is that their servers communicate with each other (each user connects only to their own server, which stores and forwards messages, just like e-mail). For instance if a Google Talk user talks to a jabber.org user, a typical message path would be something like: [EMAIL PROTECTED] - talk.google.com server - jabber.org server - [EMAIL PROTECTED] When we add inter-server communication (#3371, currently scheduled for 1.1) that's the model we should follow, because it's how the protocol already works. At the moment OLPC is only using a subset of the information. The fact that the school server is likely to be geographically close to the user is another OLPC-specific simplification, which is not required by the Jabber protocol. Most jhbuild instances use olpc.collabora.co.uk as their Jabber server; this happens to be on our server in London, but as long as you have an IP route to the Internet, it doesn't actually matter whether you're in an Internet cafe, the MIT Media Lab, the Collabora UK office or whatever. The underlying Telepathy connection managers are fully aware of which server the user is on (the part of the JID after the @); Presence Service currently hides this, in an attempt to provide a simplified view to activities. It would be entirely possible to expose additional information, or for interested activities to query the Telepathy connection manager directly. 2. get the geopraphical location of another user In future versions of the neighbor view, or through other activities, the user should be able to filter for specific XOs according to location, or school(in the case he's connected to many servers). Two children in the same school should be able to recognize each other even if they are connected through a jabber server, other then the one in the school. If what you want is geographical location, please ask for geographical location. IP address is a poor approximation, particularly since the public IP address may not be well-defined. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHIdabWSc8zVUw7HYRAjB5AKCJwAVcT43BOwTwWE3Mp4joTMVtVgCgrH6z yCWo9Rc5gR9j9va3sns+smY= =BcPE -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Michail ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On Thu, 2007-10-25 at 10:15 +0100, Simon McVittie wrote: -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! Erik ported Read over to tubes and is working on the camera app AFAIK. I'm not sure if the read bits went into git though? There were some small issues with the patch that needed be corrected before pushing to git for Read. One other user might be Etoys. Dan 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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Blankinship wrote: Record uses ip4-address, but we've just about completed Record Tubes (and it is working great). Should Activity developers assume that stream tubes will be available in both Gabble and Salut by OLPC 1.0? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIKo+UJT6e6HFtqQRAtrJAKCei2Tudo7p1nvcHS7IQsuiIMVKdgCeOEGR ISB/M1Mw+duT8XxNDuHjq+s= =UY0h -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
It seems, from your discussion like unless someone grumbles today, this should be removed immediately. And it removed within a week, even if someone grumbles... - Jim On Thu, 2007-10-25 at 10:15 +0100, Simon McVittie wrote: -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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
The feature, although not usable by the activities, it has other benefits. By observing the buddy list, you acquire instant information of the network connection go the users: when connected to channel 1 for example: 169.254.x.x address are in link-local 172.18.x.x are connected to schoolserver when connected to a jabber server: 169.254.x.x are connected through an MPP 18x.x.x are media lab 172.18.x.x are connected to schoolserver in olpc etc It is information continuously used in network testing, also useful from the users prespective: 1. in the case of connecting to multiple jabber servers, the user should be able to tell which XO in the neighbout view belongs to the same school 2. get the geopraphical location of another user In future versions of the neighbor view, or through other activities, the user should be able to filter for specific XOs according to location, or school(in the case he's connected to many servers). Two children in the same school should be able to recognize each other even if they are connected through a jabber server, other then the one in the school. It can also be useful for locating an XO in case of theft. I have also added a ticket(4405) for adding the public id in the buddy list properties. It is a small part of data(both IPs, private and public), which can be harmfully incorporated in the telepathy services. Please let me know if you agree, yani On 10/25/07, Jim Gettys [EMAIL PROTECTED] wrote: It seems, from your discussion like unless someone grumbles today, this should be removed immediately. And it removed within a week, even if someone grumbles... - Jim On Thu, 2007-10-25 at 10:15 +0100, Simon McVittie wrote: -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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
