Re: Avahi optimisations
On Tue, 26 Feb 2008 at 06:58:10 -0500, Ivan Krstić wrote: On Feb 26, 2008, at 5:48 AM, Morgan Collett wrote: actually we are normally using b64 encoding so that brought it down to 28 bytes. Using SHA-256 it's 44 bytes in the TXT record. But _why_ are we encoding at all? TXT RDATA is one or more character strings, which are each a length octet followed by up to 255 arbitrary characters treated as a binary string. Am I misremembering the RFC? You're correct, and I've replied as such to the Trac ticket. Can we move any further discussion there? Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: python activities startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 06 Feb 2008 at 23:06:19 -0500, Michael Stone wrote: Next, according to dbus-python's dbus/_dbus.py, the SessionBus returned when you call SessionBus() is cached in Bus._shared_instances[BUS_SESSION] This is not an API guarantee; neither is it API at all. I accept no responsibility if the entire platform mysteriously crashes after a dbus-python upgrade... It ought to be sufficient for Rainbow to call close() on the SessionBus after forking, but before executing the target code. This should remove it from _shared_instances automatically, causing subsequent calls to SessionBus() to create a new instance, although that code-path is not well tested and you might need some patches or a newer version of dbus-python. A better solution would be for Rainbow to avoid SessionBus() entirely, and instead use an instance of the superclass, dbus.bus.BusConnection. This does not have the weird caching behaviour at all (one call to the constructor = one instance = one D-Bus connection). The code that gets run after forking is still free to use the shared SessionBus. This may require some care in the libraries that Rainbow uses - they should all be able to accept a BusConnection argument rather than implicitly using the shared SessionBus, but they don't necessarily get this right. Libraries that can only use the shared SessionBus should probably be considered buggy anyway, though. Simon -BEGIN PGP SIGNATURE- iD8DBQFHqzX8WSc8zVUw7HYRAg6uAJ0XPz2C0az/DQ1XCAqNXZokzgFpeACdEfT3 MCpT4HahnUjTgG/rN1UFELw= =zVsd -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: python activities startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 06 Feb 2008 at 10:13:23 -0600, Klaus Weidner wrote: Would it be feasible/helpful to use the uncore approach used by Emacs? [...] Of course, any initialization done initially must not depend on external state, so for example any connections to the X server or other network connections would need to be delayed D-Bus connections, too. If a process forks or does a core/uncore cycle after opening a D-Bus connection (including, but not limited to, any call to dbus-python's dbus.Bus(), dbus.SessionBus() etc.), chaos is likely to ensue. Regards, Simon -BEGIN PGP SIGNATURE- iD8DBQFHqe2ZWSc8zVUw7HYRAhKIAKDFXV5n2QKZeBeTW1rxL1G3bHo9SwCghprv ChdeTcKOMpYXdzdxM1fFXHc= =Bb4Z -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: coping with lost connectivity (was: mesh portal discovery)
On Sat, 12 Jan 2008 at 12:00:02 -0500, Benjamin M. Schwartz wrote: This is precisely what I am saying. Telepathy should only register a disconnect if there is no way to route between two XOs. The mesh system should be designed so that moving about within the mesh, or handing off between Salut and Gabble, or switching from one internet-connected wireless network to another, does not cause a Telepathy disconnect. For the record: Telepathy, which is a standard API used on OLPC and elsewhere, does not and will not do this. A Telepathy Connection object represents a connection (e.g. a Gabble connection represents a TCP connection to the server) and we're not going to mangle the API to behave otherwise. You're right that a possible solution for activities' networking would be for some lower layer to paper over the cracks - Telepathy is the wrong layer to be doing this, but the Presence Service could do it, or so could a library in the sugar. hierarchy. However, each activity is fundamentally going to need a way to sync its state on initial connection; for at least the medium term, as Sjoerd said, we propose that the same mechanism be used to resync after connectivity loss. If we have enough developer time to be able to work on library code for activities' networking, it's likely that the API will involve an activity-supplied resync callback that's called when initially joining an activity, and when connectivity is regained after a connection loss. In each of these cases, the path between XOs remains routable, with a gap of at most a few seconds. I'm not convinced this is even technically feasible, given the constraints of the quality of the underlying network (if the packets aren't arriving, there's nothing we can do about it). It's certainly a much lower priority right now than making the servers scale properly. Many of Sjoerd's bugfixes to Salut have been to do with detecting and signalling loss of connectivity - not in the sense of I lost my IP address, but in the sense of I'm sending packets to Fred and he's not acknowledging any of them, so either he's not receiving them or I'm not receiving the acknowledgements. No amount of programming will fix packets just not turning up, so the only improvements we can bring here are by tweaking the trade-off of bandwidth use vs timely error recovery. This suggests that however much we can improve the API, activities will still have to be able to deal with situations where other users fall off the network, in a more or less graceful way - and if you can do that, then you can use the same mechanisms to resync after connectivity changes, in the way that Sjoerd suggests. We can probably never make it entirely transparent, because however quick it becomes to reconnect after connectivity loss, you can't guarantee that you haven't lost messages; and in a message-passing system, as soon as you can't make that guarantee, the only way back to a consistent state is to ask someone else what's going on, which is exactly the resync I'm talking about. Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 09 Jan 2008 at 22:17:18 -0500, John Watlington wrote: We have a presence service which provides a way for P2P applications to find one another, even after the IP changes. Presence Service isn't magical. If a laptop's IP address changes, in the link-local backend (Salut) this will most likely appear as a disconnect + reconnect (and the user will leave all shared activities they were currently in). This is somewhat unavoidable, but if it's a hard requirement that Salut do its best to survive IP addresses changing, file a bug against telepathy-salut. In the server-based backend, an IP address change *will* cause a disconnect and reconnect. This is definitely unavoidable, since XMPP uses a long-lived TCP connection to the server. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHhd6wWSc8zVUw7HYRArqcAKCsl70pz9HTAefk05uUulh+9NJzmgCfWzZX sBzd9bWu/1RpvBi+GGTnIfk= =0pb8 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: server-to-server communication (was: A jabber hosting offer)
On Sat, 05 Jan 2008 at 22:01:03 -0700, drew einhorn wrote: If we are going to have small local communities instead of one big one, the we need to be able to contact multiple jabber servers The underlying protocol of the server-based collaboration is XMPP. In XMPP, you never need to connect to more than one server unless you need more than one identity (e.g. personal and work addresses) - servers communicate among themselves to forward their users' messages, just like e-mail (server federation in XMPP jargon). Server federation is a high priority as a future feature, but the current Activity protocol doesn't scale beyond one smallish server, because of the Shared Roster hack. We have people working on a replacement Activity protocol involving a server component that acts as an activity registry, that can work correctly across federated servers, and doesn't require that everyone is on everyone's roster (buddy list) at the XMPP level (this is the Shared Roster hack that causes us so much trouble in both ejabberd and Openfire). In principle, once we get a scaleable activity protocol, (a) we'll be able to fit many more XOs on one server, and (b) there'll just be one big worldwide community (school servers can become part of the existing XMPP network, which includes e.g. jabber.org and Google Talk) and kids will be able to add friends on other servers. Obviously, there are UI and privacy issues to be solved before we open up connectivity between servers, but it's definitely the plan. So, in summary: yeah, we're on it :-) Regards, SMcV (no longer working on OLPC myself, but previously part of the Collabora OLPC team) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] [XoIRC] Make default nicks more meaningful (#5385)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 22 Dec 2007 at 18:36:49 -0600, Phil Bordelon wrote: By default, XoIRC uses the username when another nick is not provided. Alas, for every XO, this is 'olpc'. This makes for rather a mess in the IRC channels. This patch instead generates a more-meaningful nick: * It takes up to 11 alphabetic characters from the user's Sugar nick; * it appends a hyphen; and * it adds the last four hexadecimal digits of the MD5 hash of the user's public key. If you instead chose the *first* few hex digits of the *SHA-1* of the user's public key, it'd match the beginning of the XO's default userIDs in the normal activity sharing/chat mechanism, which may be useful if you're trying to sort out network issues. In the XMPP/Jabber backend, the account Sugar currently tries to create is the hex SHA-1 of the public key, plus @, plus the server name. In the link-local (Bonjour) backend, Sugar uses the first few hex digits of the SHA-1 of the public key (I forget how many - I think it's 6 or 8?) plus @ and the XO's hostname (which defaults to xo-11-22-33 if the MAC address is xx:xx:xx:11:22:33). Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHdPiaWSc8zVUw7HYRAuxnAKCOqP2SNxN834x18t2MxVdQ+8cdowCfWsEv 13CP6SDIgcKyGgYjc6zrzyI= =9l2p -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fake mesh over IP.
On Wed, 05 Dec 2007 at 11:36:08 +0200, Jani Monoses wrote: Is there an easy way of using salut on the regular (non-mesh) wifi interface? That would cover only laptops on the same LAN and be suited for a school laboratory or a household. Join an ordinary wifi access point and this will happen. (This is how Salut is most often tested, in fact.) Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
On Fri, 30 Nov 2007 at 07:51:38 -0500, Eben Eliason wrote: I'm not sure that a multi-way video conference is even feasible yet. It's certainly not in the short term - the Telepathy and Farsight frameworks, and the underlying protocols they currently use (Jingle), only support 1-1 audio/video calls at this point, and we'd need a lot of API and protocol design work to even start on this. Whenever we've talked about video-conferencing in the office, our VoIP people's opinion has been that in practice we'd probably also need a (fairly hefty) server to multiplex the streams for us, which doesn't work so well in the OLPC use-case anyway. (disclaimer: I might be wrong, opinions might have changed; I'm not a VoIP hacker myself) Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 07 Nov 2007 at 17:49:52 -0500, Eben Eliason wrote: Just a mention, since this thread is getting a lot of attention. There is an added visual element which should be in play here, according to the design. There should be an intermediate state before XOs disappear from the view, as outlined in: http://dev.laptop.org/ticket/3657 As outlined in that bug, this has nothing to do with the Telepathy backends and PS, it's just a layout/presentation tweak in the Sugar shell (and indeed, the bug is assigned to sugar, not presence-service). Getting more information from the network, via Telepathy and PS, to the shell would be necessary to take it beyond what you suggest in comment#2, but is not feasible in the short term (i.e. Update.1). Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHMukAWSc8zVUw7HYRAtF/AKDlmpJsI08JeWrYlebdtGHovF4oSgCfeEAV ZIXr8UwO6guqBRbkbvlVivw= =dRfa -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 07 Nov 2007 at 13:36:45 -0500, Giannis Galanis wrote: I can definitely try to arrange this. But, can you please send me the tarball to test it in the mean time? Will do. I don't think it's feasible to implement correct handling of PS restarts in sugar.presence for Update.1, so unless the release engineering team specifically tell me to, I won't be addressing that bug until a later release. Ok, i will reassign the bug to presenceservice. As long as restarting sugar works, we can stick to that for now. No, it's not a Presence Service bug, it's a Sugar bug (the sugar.presence module is part of Sugar, and it's that module that will have to be changed). Please assign to component Sugar, with owner smcv or morgs, and keep the 'collaboration' keyword (we use that to keep track of collaboration-related bugs in other people's components). $getent hosts jabber.laptop.org 2001:4830:2446:ff00:201:6cff:fe07:68ec jabber.laptop.org - frequent reply 18.85.46.41 jabber.laptop.org --rare reply $ping jabber.laptop.org PING jabber.laptop.org (18.85.46.41) 56(84) bytes of data. 64 bytes from jabber.laptop.org (18.85.46.41): icmp_seq=1 ttl=63 time= 67.4 ms ... $telnet jabber.laptop.org 5222 blabla... connected hello replied with an xml packet with xml-not-well-formed included so it seems that it is a PS issue. Perhaps it is not waiting long enough, or doesnt make enough tries when trying to connect. I have reassigned the bug to presenceservice. Was all this done on a machine exhibiting the failure you mention? PS makes an unlimited number of connection attempts, with a short delay between each one (we should probably change this to use an exponential backoff process so the delays get longer as you're offline for longer, up to a maximum of perhaps 10 minutes). What I meant here is, Does the PS check if jabber server is accessible, and then runs telepathy-gabble?, or this is one of the tasks of telepathy-gabble?, which as I see you replied to Like I said, the PS doesn't check whether the server is accessible, it just optimistically tries to connect anyway. I believe this is the right thing to do. have you tried to check connecting to gabble with the laptops available there? Does it work fine? Not recently with XOs, I must admit (downloading filesystem images takes a while) but it's always worked fine from my jhbuild. Perhaps you can connect to an XO here with ssh, and debug real time what is exactly happening. Talk to me on #sugar when you have an Internet-accessible XO that's exhibiting this problem. I'm smcv on IRC. it was suggested (i think bug 4700) that it is possible that the jabber server might have a limit in number of users. Is this possible? It's possible, but it's always worked for me... Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHMtxBWSc8zVUw7HYRAj3fAJ95oDyvE30EXR3UP4/muZdWtbAE3ACggXbS EEhhwpa+vAW+7uwvuIMkK/g= =uOn0 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Compiler optimization for Geode, migrating to F8, build system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 05 Nov 2007 at 15:13:39 -0500, Bernardo Innocenti wrote: Yes. The problem is that building a package or two in a separate environment is feasible, but rebuilding a whole distribution from scratch is *hard*. It requires you to install and configure local copies of pilgrim, mock, createrepo, yum... If this sort of thing is of interest to people, it's likely to be worth examining how Debian does it - there are regular efforts to rebuild all of Debian, usually for mass-bug-filing purposes (e.g. filing bugs against all packages that don't build correctly with a newer version of gcc, so that those bugs can be fixed before the newer version becomes the default). Because of Debian's decentralized nature, much of its infrastructure is in a form that can be used to set up third-party repositories without any particular permission or help from Debian itself. In particular, Debian's debootstrap package (used to construct a minimal chroot with a particular version of Debian) is so useful that it was adopted for use as the first stage of the official installer (the installer now uses a C reimplementation, cdebootstrap, but the principle is the same), and the schroot and sbuild packages (used to set up a chroot, and build packages in a chroot with automatic installation of build dependencies, respectively) are also very well constructed. http://buildd.debian.org/ runs the official package autobuilders, but there are a number of third-party clones running the same software, such as http://experimental.ftbfs.de/. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHMEtTWSc8zVUw7HYRAn/oAJ4nPq/cM9jWfuzBwWmpgmN6F78KaACgr26O dt2azi6/rgiRedVIrPQy7fI= =2eAt -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In reply to your previous mail, iff means if and only if. It's often used by mathematicians. On Tue, 06 Nov 2007 at 03:23:39 -0500, Giannis Galanis wrote: What does proper notification mean? Which are the cases that it happens? If Salut is explicitly asked to disconnect, it will tell Avahi to delete all its mDNS records (this actually consists of re-sending all the records it was advertising, with the Time To Live set to 0 seconds). This is sometimes referred to as a goodbye packet. See http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt section 11.2 Goodbye Packets. The only time we'll currently do this is when switching off Salut because Gabble has connected successfully. Probably this is not if an XO moves slowly to a place with poor connectivity. This is never done in response to network conditions - we can't know that we've lost network connectivity until it's too late. If the Time To Live on our mDNS records expires, that should have the same effect; however, as Sjoerd explained, we currently ignore that, because the 1CC mesh network is apparently unstable enough that the TTL sometimes expires even for laptops that are actually present. In the case of a temporary(short) disruption of connectictivity, how much time does it generally take for it to return? You mentioned that in the past XOs were appearing and disappearing constantly. This implies that the common drop of connectivity is in the scale of few seconds. You tell me! :-) I don't have enough XOs to replicate the conditions of a large mesh network like 1CC, so I can't comment on packet loss rates. Perhaps Dan Williams (who used to maintain Presence Service) could help you. If it is lost for more than a few minutes, than it is not bad for the XO to leave and return. So I believe that 1h or even 10min are too long timeouts. I believe we're currently using Avahi's default timeouts, which are those recommended in the mDNS draft (linked above). If I'm right about that, then we're using 120 second TTLs for the SRV and A records. Assuming Salut and Avahi follow the draft's recommendations, this means that for the records representing activities, buddies and laptops, if we haven't seen an annoucement of a particular record, we will: - - re-query after 96 - 98.4 seconds; - - if no reply, re-query after 102 - 104.4 seconds; - - if no reply, re-query after 114 - 116.4 seconds; - - if no reply, assume the record has vanished after 120 seconds. (In each of the ranges given for the re-queries, the exact time is chosen at random, to avoid simultaneous queries from everyone in the network.) The timeout is reset as soon as we see any announcement of a record. The only ones whose disappearance matters are the SRV and A records - if a TXT record fails to disappear when it shouldn't, we don't really care. TXT records have a substantially longer timeout (the draft recommends 75 minutes). There are a couple more things I would like to address: 1. Is there a way to restart the presence service? In that way we can resolve a weird state. Will killing restarting the porcess work? Only if client code that accesses the PS is amended to cope with this (I just filed #4681 to represent this). Until #4681 is closed, if the PS was restarted, nothing would work - use Ctrl+Alt+Backspace to restart all of Sugar. Please see the bug for more details or to reply. 2. At what point in the source code, the presence serivce i.will try to connect to the jabber server? ii. run gabble? I'll answer (ii.) first. Gabble is automatically run by the session bus (dbus-daemon) via service activation, the first time the Presence Service uses it, if it isn't already running. So there is no explicit code in the PS to run Gabble. OK, now (i.): When Network Manager indicates that we have a valid IP address, we run the _init_connection method of the ServerPlugin instance. If the Gabble connection fails, we schedule a timer (currently 5 seconds) and retry running _init_connection when the timer runs out. (classes TelepathyPlugin and ServerPlugin, methods _init_connection, _reconnect_cb, _could_connect, _handle_connection_status_change.) What _init_connection does is: If there's already a Gabble connection and it's connected, it'll be used. (class ServerPlugin, method _find_existing_connection). Otherwise we make a new connection (method _make_new_connection). ServerPlugin (src/server_plugin.py) inherits from TelepathyPlugin (src/telepathy_plugin.py) so some of the methods I mentioned are defined in TelepathyPlugin, some in ServerPlugin, and some are defined in TelepathyPlugin but overridden in ServerPlugin. ii. what type of communication is taking place between NM and PS D-Bus messages, on the system bus. iv. the internet connectivity is detected by NM and sent to PS, or detected by PS Internet connectivity isn't really detected, as such. The PS listens for signals from Network Manager that
Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
On Tue, 06 Nov 2007 at 12:05:59 +0200, Morgan Collett wrote: Giannis Galanis wrote: 1. Is there a way to restart the presence service? In that way we can resolve a weird state. Will killing restarting the porcess work? Killing it will result in it being restarted. However, Sugar remains in an inconsistent state, with buddies stuck on the mesh view if they left while PS was not running, since PS never told Sugar that they left. The situation would actually be worse than that, see #4681. Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mandatory Changelogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 27 Oct 2007 at 18:55:34 -0400, Michael Stone wrote: Dear Sugar and Devel, ChangeLogs in the format described on http://wiki.laptop.org/go/Build_system#ChangeLog_Format are now MANDATORY for package inclusion. Please write yours. How does this work for Koji users? I build the OLPC Telepathy components for what-was-FRS-last-time-I-looked in the OLPC-2 stream in Koji. Will they be integrated into Joyride automatically, or do I have to download the RPMs (assuming that's even possible) and re-upload them via my public_rpms? If they're integrated automatically, how and where do I write changelogs? I'm happy to write the RPM %changelog in the desired format if that's what you want... Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHJbPmWSc8zVUw7HYRAu7uAJ48urtIwmlI4/MMSsgxNBYD7OAcEgCfbwp3 vj+9tWFehBxQ7azm1xJYYFk= =BF29 -END PGP SIGNATURE- ___ 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 to be replaced by stream tubes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 25 Oct 2007 at 10:37:50 -0400, Benjamin M. Schwartz wrote: 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? Yes, I think you should. They work in Gabble at the moment, so you can test collaboration, as long as you make sure you have Internet access. They'll work in Salut (server-less link local collaboration) soon - we have a branch in which they work, but I'm not very happy with the implementation, so it's not in builds yet. If you were previously using ip4-address, using the IPv4 socket type for stream tubes will give you the nearest API match. I patched Read to use stream tubes (patches are attached to #4927) if you want an example. For something like Record it may be best to use a hybrid solution - D-Bus tubes (because of their ability to broadcast) for new photos, and stream tubes (because of their potentially higher efficiency) for newly joined buddies to catch up with the activity state. That's entirely possible, and I can probably help you with the API, although obviously fixing up PS, Gabble and Salut will have to take priority for me. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHILUaWSc8zVUw7HYRAhTXAKCHuBkdvDOWzhyodPuzXjPypfWSbgCgkPpa O4S+f2hf00k6RrQaJIf6KeI= =uUlt -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New FRS blocker #4438 - Salut collaboration not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In Joyride builds 89 and up, Salut Tubes channels don't work due to a mismatch between the low- and high-level implementation. Guillaume has a fix, I'm filing this bug to track the process of getting it into builds. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHH1ljWSc8zVUw7HYRAvpDAKCyc9pW9EeoaGpbpUSb420tN6gflwCfTp1o 3acclgVwicofwLE+r8VXA0s= =ZYMe -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Presence service bugs/enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 23 Oct 2007 at 07:55:57 -0400, Kim Quirk wrote: 1. The presence service should detect more efficiently the internet connectivity and switch to gabble when appropriate(4193) As I commented on the bug, we need debug logs - this should have worked, and without logs we can't know why it didn't. 2. In link-local XOs are seen in neighbor view but cannot be shared with. Sometimes they are not connected to the mesh anymore, but still present. In some such cases the avahi-browse cannot resolve the services of the corresponding XO. This is high priority but i dont have a log file in a blocking case, although i have experienced it in build617(4402) Sjoerd is the expert for this one. 3. Ability to switch from gabble to salut manually using the options: auto,salut,gabble(4403) As I commented on the bug, I'd like some more idea what the requirements are for this. 4. Ability to keep an activity alive when passing from salut to gabble and vice versa. This can occur automatically when internet connectivity is dynamically lost or recovered(4404) As commented: This is difficult, and can't be fixed purely within PS - activities will need to handle the switchover themselves, since we don't and can't know how to resynchronize arbitrary activities (the activity can't assume that everyone migrates at the same time). I don't think this is feasible for 1.0. 5. In gabble, the public IP must be available in the buddy list, or at least be accessible through the jabber server upon request(4405) As I commented, the private addresses are going away soon too - we only have them because some activities (Read) haven't been ported to use Tubes for collaboration yet (bug filed). The only reason they're visible in the dev console is that it's meant to give a complete picture of what the PS is thinking, so it should expose all information the PS knows about. The XO might not *have* a public IP, might not be usefully reachable at its public IP, (e.g. when behind NAT), and so on, so this is not generally useful information for PS to provide. 6. The jabber servers should be switchable(to change from one to the other) in a neater way then accessing the config file and rebooting. This can probably be invoked by sending smth like ..xmlns:stream= http://etherx.jabber.org/streams; to=jabber.laptop.orgas i noticed in the log files. If it is simple to apply, can you describe how it can be done properly?(not on trac) No, you can't send a new stream:stream element to the server to magically turn it into a different server :-) Gabble needs to be told to open a new TCP connection to the new server and do XMPP over that, and drop its old connection. This is entirely possible; Gabble already supports connecting to many servers simultaneously, if this is ever needed. It would be possible to add API to the Presence Service to drop its connection to the current server and connect to a different server. What are the requirements for this task? Is there a UI requirement that we should be supporting? I'd guess that this would be part of the same UI that handled switching between Gabble and Salut? Parts of the PS theoretically support connecting to arbitrarily many Telepathy connections (any combination of Gabble and Salut), but sharing becomes awkward in that case (you can't yet share across multiple servers, and sharing the same activity across XMPP and link-local at the same time is a minefield). Activities involving XOs from multiple servers are currently planned for 1.1; it's too early to say whether that's overly optimistic. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHHfQhWSc8zVUw7HYRAig+AJ0XzTzFGnx5MeOpbAZ5/sosbGl3uwCgwS0y BoVS+nQu5DrEYehaQpMUD7k= =HJhs -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Salut (link-local) protocol changing - don't expect interop between versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a heads-up for anyone who isn't already aware: We're replacing the Salut (link-local collaborative backend) rMulticast protocol with a better version, over the next week or so (bug #4044). This is an incompatible change; there may in fact be more than one incompatible change involved, if we have to change the protocol further when it's had larger-scale testing. As a result, until further notice, Salut is not expected to be compatible between different versions. Please do not report bugs in link-local (serverless) collaboration unless all participants in the activity are running exactly the same snapshot of Salut (e.g. the same XO image). We'll freeze the network protocol again between now and the 1.0 freeze. The improved rMulticast protocol either fixes, or will enable us to fix, #3294, #3969, #3465, #3338 and possibly #4127; we might also take the opportunity to improve the mDNS part of the protocol. Checking the version on an OLPC: rpm -q telepathy-salut Checking the version in jhbuild: ls -d source/telepathy-salut-*, see which one has the latest date in the directory name Regards, Simon on behalf of the OLPC Telepathy team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHF4ZmWSc8zVUw7HYRAqtDAJ9AWv5rE8jZzl84zlZW+MRLd6zxqACfRD3z OgPyBcBGKb1tZjbY+PT432I= =ouwQ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: keyboard layout image license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 14 Oct 2007 at 11:43:48 -0400, Ed Trager wrote: Based on my understanding of a recent discussion I had with licensing experts at the institution where I currently work (USA), LGPLv2 or Apache or other software licenses which Albert mentioned are not applicable to a visual image work. A Creative Commons license is what we want. Public Domain is not recommended. Bundling or including CC-licensed image artwork in a software package is of course allowed so long as you state the license and provide attribution, so I see no need for multi-licensing under LGPL or Apache or whatever. If the artwork is bundled in a software package, you should be aware that that software package will not be allowed into Debian, or other distributions that use the Debian Free Software Guidelines (on which the Open Source Definition is based - so these are quite influential guidelines!), unless the artwork is removed. Debian's criticisms of the Creative Commons Attribution license (and derivatives) as a Free Software license can be found here: http://people.debian.org/~evan/ccsummary.html I must admit, I can't see why images of keyboard layouts need to be protected by copyright. A very simple permissive non-copyleft license like the Expat (MIT/X11) license would seem more appropriate, if placing them in the public domain is problematic. It's also a bad idea to recommend a Creative Commons license without explicitly specifying which one, since the CC licenses range from CC-BY (clearly intended to be a permissive non-copyleft Free Software license, although it has the issues I linked above) to CC-NC-ND (clearly incompatible with the aims of the free software movement in that it denies permission for commercial use and derivative works). Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHEy9KWSc8zVUw7HYRAgPRAKCURHFsZVi9ciVFrcYhwR/YizU2RwCgtpaM zZRJdockLuj4qjsXTvHDy78= =fvVs -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: funny behaviour gtk+python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, didn't send my reply to both the mailing lists. Replying to myself to preserve the cross-posting. On Thu, 04 Oct 2007 at 14:44:08 +0100, Simon McVittie wrote: On Thu, 04 Oct 2007 at 14:23:58 +0100, Victor Lazzarini wrote: Just to add a little to say that this particular csound error is issued when there is an incorrect numeric format, say 11.B or 11.1A. In here, if I only use integers, there is no error, but all decimals are raising the error. Here's the Csound code fragment that issues the error: ... tmpVal = (MYFLT) strtod(s, tmp); strtod() respects the process' locale settings. Importing gtk probably pulls in the locale settings from the environment and sets them as the process-wide locale (see setlocale(3)). GLib has a function g_ascii_strtod(), and Python has PyOS_ascii_strtod (which is actually the same function). csound ought to be using something equivalent to this to parse locale-independent decimals, rather than using the C library's strtod(). See http://www.python.org/dev/peps/pep-0331/ for more details. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHBO76WSc8zVUw7HYRAo9QAKDQTOgMxUF1v6idnj51nHr7ek3xAgCg5OLj QlEtQT1TYSccWjnM+0pktt8= =VpHU -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
