ip4-address buddy property - still needed?
-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
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?
On Oct 25, 2007, at 5:15 , Simon McVittie wrote: > 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. > > 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. Etoys still uses it. I'm currently rewriting this to use tubes, intended to be completed before 1.0. If you remove the property, please raise #3758 to blocker priority. Or maybe open a new blocker for tubification. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
> 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. > > 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. Record uses ip4-address, but we've just about completed Record Tubes (and it is working great). ___ 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
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?
Several parts for your replies refer to issues we have discussed before. The tickets 4463,4405,4404,4403 include the new requirements and enhancements for the presence service, in benefit of user+developer To summarize 1. User+devel should be able to switch between gabble to salut manually using the options: auto,salut,gabble (4403) 2. User+devel should be able to connect/disconnect to one (or many, in the future) jabber server (4463) 3. User+devel should have access to public+private IP (4405) There are several reasons for each one of these. Now, if you observe them combined, the importance of IP information is: user's prespective: assume for example 60 XOs are connected to a public jabber server(e.g. jabber.laptop.org). Five of these belong to the same school. They should be able to filter themselves. devel's perspective: 1. From 1 XO we can test intantly which XO's are connected in a specific configuration 2. IPs give irreplaceable information regarding whether the XO is connected to MPP, AP, schoolserver, NAT etc 3.(very important). when an XO is connected is connected to an MPP, we need to now the name of it. The buddy list links IP with name and many more regarding the privacy issue of giving away the IP, regarding that all p2p or IM offer this capability , it shouldnt be an issue, yani On 10/26/07, Sjoerd Simons <[EMAIL PROTECTED]> wrote: > > 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?
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?
Yes, we need a relatively user-friendly way to query for that information. I don't reall care what it is called as long as I can instruct somebody to bring it up with a minimum number of clicks. M. Sjoerd Simons <[EMAIL PROTECTED]> wrote on 10/30/2007 08:59:36 AM: > 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 11/3/07, Walter Bender <[EMAIL PROTECTED]> wrote: > Did this ticket every get opened? I think a lot of problems would be solved > if you could open the various consoles on someone else's XO... I haven't seen tickets yet. Opening Log and Analyze remotely should be relatively easy. Also I think integrating and properly supporting Pascal's log collector would go a long way in facilitating testing. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
Did this ticket every get opened? I think a lot of problems would be solved if you could open the various consoles on someone else's XO... -walter On 10/30/07, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > > 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 > -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On 10/30/07, Michail Bletsas <[EMAIL PROTECTED]> wrote: > Yes, we need a relatively user-friendly way to query for that information. > I don't reall care what it is called as long as I can instruct somebody to > bring it up with a minimum number of clicks. I think key bindings for both Log and Analyze could be useful for developers and maybe they could also be a quick way to instruct people. Marco ___ 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?
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
