[sugar] [ANNOUNCE] Gadget 0.0.3 released
The "Down on the Farm" release. Highlights: - According to our tests, you should use at least ejabberd 2.0.2 to have Gadget working properly. See README for details. - Fix handling of view close messages". Tarballs: http://dev.laptop.org/pub/gadget/ Regards, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Presence Service
Le jeudi 20 novembre 2008 à 12:04 +0100, Bert Freudenberg a écrit : > On 20.11.2008, at 11:52, Morgan Collett wrote: > > > On Thu, Nov 20, 2008 at 12:24, Bert Freudenberg > > <[EMAIL PROTECTED]> wrote: > >> On 20.11.2008, at 10:17, Morgan Collett wrote: > >>> Collabora have therefore suggested replacing Presence Service with a > >>> combination of Mission Control and moving functionality up into > >>> sugar-toolkit and the activities themselves, so that everything is > >>> talking Telepathy and not some arbitrary abstraction of an > >>> abstraction > >>> framework. > >> > >> > >> Will the DBus interface to Mission Control be available by then? I > >> only saw a year-old proposal for it. If not, it will take a > >> considerable amount of boring work to migrate Etoys. > > > > The plan would have to include providing the same or similar API for > > non python activities as the current PS API - without failing to > > remove unnecessary indirection and abstraction... > > > Just to clarify: I was specifically referring to a D-Bus API. An > activity written in C could easily use the existing C-level API to > Mission Control. Not all "non-Python" activities are created equal :) The new mission control (5.x) will implement a standardised D-Bus API as any other Telepathy component. Some of these API's were already merged to the Telepathy specification [1]. G. [1] http://telepathy.freedesktop.org/spec.html ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] sugar-presence-service 0.83.1 released
A new release of Presence Service is available at: https://dev.laptop.org/pub/sugar/sources/sugar-presence-service/sugar-presence-service-0.83.1.tar.bz2 Enhancements: * dev.laptop.org #7581: Don't ignore buddies without keys. This improve interoperability with non Sugar client. * dev.laptop.org #7849: Display PS version in the log. * Use gconf to get Sugar profile settings. * dev.laptop.org #8444: Don't rely on the roster to check if a contact handle is channel specific or not. So PS will properly create Buddy objects discovered using Gadget. Furthermore, this workaround has the nice side effect to improve compatibility with bugged shared roster (as the one of ejabberd). Fixes: * dev.laptop.org #5618; Discard invalid handles if InspectHandles failed. Regards, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] telepathy-glib and glib 2.16 dependency
Le vendredi 17 octobre 2008 à 21:46 +0200, Marco Pesenti Gritti a écrit : > Hello, > Hi Marco > commit dd2c13d56672d7ff7e69f59138c1bf3493e3dddf > Author: Guillaume Desmottes <[EMAIL PROTECTED]> > Date: Fri Oct 17 17:37:36 2008 +0100 > > upgrade to telepathy-glib 0.7.17 > > This adds a dependency on glib 2.16. It would mean to drop support for > Fedora 8 and the equivalent Ubuntu version. My plan so far was to do > it after Ubuntu/Fedora releases (the logic being to keep support for > two latest releases of these major distributions). > > Can you explain the reason of the glib version bump so that we can > better decide on it? The new telepathy-glib and telepathy-gabble use glib 2.16 new API. You can revert my commit for now, we don't need this new tp-glib yet. But we'll do soon as we'll need the futur Gabble release for Gadget. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [ANNOUNCE] Gadget 0.0.2 released
The "Monster Lake" release. Highlights: - Support for constraining activity search results. - Various bug fixes. - Adds load simulation tools for testing purposes. - Support for multi criteria search. Tarballs: http://dev.laptop.org/pub/gadget/ G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proposed: Cerebro status meeting
Le vendredi 17 octobre 2008 à 13:45 +0200, Morgan Collett a écrit : > I'd like to catch up on the progress of Cerebro, telepathy-synapse and > other ideas for scalable link local presence before we get into > planning this feature for Sugar 0.84: > http://sugarlabs.org/go/DevelopmentTeam/0.84/Collaboration#Scalable_link_local_presence > > Can we have a meeting next week to see where things are at? > > Channel: #sugar-meeting > > Proposed time: Wednesday Oct 22, at 14:00 UTC > (http://timeanddate.decenturl.com/1400utc) or 17:00 UTC > (http://timeanddate.decenturl.com/1700utc) I'd prefer 14:00 UTC G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congrats to Telepathy
Le mercredi 24 septembre 2008 à 19:05 -0400, Benjamin M. Schwartz a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Congratulations are in order, I think, for the Telepathy developers. Gnome > 2.24 was just released, and from Thank you very much. :) Note that we have some plan to make sugar uses Telepathy in a much similar way as we do on the desktop. That should lead to a better interoperability with non-sugar client and increase code reuse. More on this, hopefully, soon. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Telepathy] ANNOUNCE: telepathy-salut 0.3.5 released
Le mercredi 17 septembre 2008 à 20:14 +0200, Morgan Collett a écrit : > For those not on the Telepathy list... And as said, on #8441 there is a backport of this fix in the rpm package which seems to fix the issue. > -- Forwarded message -- > From: Guillaume Desmottes <[EMAIL PROTECTED]> > Date: Wed, Sep 17, 2008 at 18:38 > Subject: [Telepathy] ANNOUNCE: telepathy-salut 0.3.5 released > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > > > telepathy-salut 0.3.5 (2008-09-17) > == > The "Please don't flood my network" release. > > Tarball: > http://telepathy.freedesktop.org/releases/telepathy-salut/telepathy-salut-0.3.5.tar.gz > Signature: > http://telepathy.freedesktop.org/releases/telepathy-salut/telepathy-salut-0.3.5.tar.gz.asc > > > This release fixes an annoying bug causing Salut announcing all the OLPC > activities which are present on the network. You should consider > upgrading if they are OLPC XO's running on your network. > > Enhancements: > > * Add a test framework > > Fixes: > > * Only announce OLPC activity we actually joined (dev.laptop.org #8441) > > > > Regards, > > >G. > > ___ > Telepathy mailing list > [EMAIL PROTECTED] > http://lists.freedesktop.org/mailman/listinfo/telepathy > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [ANNOUNCE] Gadget 0.0.1 released
Hi, Daf and I are happy to announce the first release of the Gadget XMPP component. See http://wiki.laptop.org/go/Gadget for more info about Gadget. Tarball: http://people.collabora.co.uk/~cassidy/gadget-0.0.1.tar.gz The "live CDs are not usually meant to automatically format your disk" release. This is the first version release of the XMPP component Gadget. It implements most of the basic expected features including: - subscriptions management - buddy views (by buddy properties, by alias and random) - activity views (by activity properties, by participants and random) Note this is an alpha quality release. It certainly contains lot of bugs and the underlying XMPP protocol is still subject to changes. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] sugar-presence-service 0.82.2 released
A new release of Presence Service is available at: https://dev.laptop.org/pub/sugar/sources/sugar-presence-service/sugar-presence-service-0.82.2.tar.bz2 The "I should use pyflakes more often" release. This brown paper bag release fixes a stupid name error in #5618 fixe. Regards, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] sugar-presence-service 0.82.1 released
A new release of Presence Service is available at: https://dev.laptop.org/pub/sugar/sources/sugar-presence-service/sugar-presence-service-0.82.1.tar.bz2 The "One more bug fixed" release. Fixes: * dev.laptop.org #5618: PS should drop handles causing InspectHandles failing Regards, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar-presence-service branched for sucrose-0.82
sugar-presence-service has been branched for 0.82. The main goal for this cycle is the Gadget [1] integration which should hopefully increase the scalability of server-oriented collaboration. G. [1] http://wiki.laptop.org/go/Gadget ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] sugar-presence-service 0.82.0 released
A new release of Presence Service is available at: https://dev.laptop.org/pub/sugar/sources/sugar-presence-service/sugar-presence-service-0.82.0.tar.bz2 The "Woo I'm stable!" release. No code change since 0.81.4, the point of this release is to sync version number with Sucrose 0.82.0. Regards, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] How do I connect to a Jabber server ?
Le mardi 05 août 2008 à 12:24 +0100, Gary C Martin a écrit : > On 5 Aug 2008, at 09:46, Morgan Collett wrote: > > >> The xochat.org jabber server is the one I seem to reliably attach to > >> for my XO testing, though I'd love to see an official developer > >> jabber > >> server, so as not to pester real G1G1 users with my tests, and so we > >> can 'eat our own dogfood' in a dev environment**. Connecting to a > >> remote jabber server is currently the way to see and share with other > >> remote users*** in the neighborhood. > >> > >> ** perhaps Sugar Labs could run such an environment? > > > > Collabora run a server which is the default setting for jhbuild: > > olpc.collabora.co.uk > > That's good to hear re-confirmed, but I've not seen any buddies/ > activities shared on olpc.collabora.co.uk for weeks/months. I'd just > assumed your server was always borked by lots of connections, or in > some unstable dev status, so I had switched over to xochat.org which > always seems to respond and have buddies showing. > > Using your recent "nc olpc.collabora.co.uk 5222" trick I can now see > olpc.collabora.co.uk is responding with some xml just fine. So, is no > one else using it, or should I do some debugging? Are you running a > dev version of a jabber server that's doing something different? olpc.collabora.co.uk was recently reinstalled to a new ejabberd server in order to test Gadget. The shared roster hack was removed which improve stability but doesn't automatically display all the connected buddies anymore. Gadget should solve that, I plan to merge it at the beginning of the 9.1.0 cycle. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] July 31 - Sucrose 0.81.6 Tarballs Due
Le mercredi 30 juillet 2008 à 19:25 +0200, Simon Schampijer a écrit : > Dear maintainers, > > the next development release is tomorrow the 31th July. Please provide source > code > tarballs by the end of tomorrow for the following modules: Not code change in sugar-presence-service since 0.81.4. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Presence Participant ID
Le mercredi 30 juillet 2008 à 13:57 +0200, Bert Freudenberg a écrit : > Hi, > > I just noticed the addition of this function to the PS API: > > • SearchActivitiesByParticipants(au) → o > • Search for activities having the given participants. > • Returns: the view representing the result of the search. > > What participant id does this take? Presence "participants" are > buddies, so I would have expected this function to take an 'ao' > argument. fixed. nice catch :) G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Presence Participant ID
Le mercredi 30 juillet 2008 à 13:57 +0200, Bert Freudenberg a écrit : > Hi, > > I just noticed the addition of this function to the PS API: > > • SearchActivitiesByParticipants(au) → o > • Search for activities having the given participants. > • Returns: the view representing the result of the search. > > What participant id does this take? Presence "participants" are > buddies, so I would have expected this function to take an 'ao' > argument. You are completely right. I also noticed this problem this morning and I'm working on it atm :) G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Le jeudi 24 juillet 2008 à 09:59 +0200, Guillaume Desmottes a écrit : > The plan with Gadget is to allow user to request random buddies (and > activities) or perform search based on different criteria. As you can > see on [1], currently only search based on buddy properties is > implemented but we plan to add alias search soon (maybe next week if you > really need it). I implemented search by alias using Gadget. The gadget branch is not merged yet and the Gabble one is http://monkey.collabora.co.uk/telepathy-gabble-gadget/ See http://people.collabora.co.uk/~cassidy/spec-olpc-gadget.html#org.laptop.Telepathy.Gadget for the API. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] File Transfer (was Sugar mtg minutes, 24th July 2008)
Le vendredi 25 juillet 2008 à 10:43 +0200, Morgan Collett a écrit : > On Fri, Jul 25, 2008 at 10:07, Guillaume Desmottes > <[EMAIL PROTECTED]> wrote: > > About file transfer. There is currently an intern working on the new FT > > spec and its implementation in Salut. So we should hopefully have > > something working at the end of this summer. > > Once the spec merged, we could implement it in telepathy-synapse (the > > Cerebro connection manager) too. > > Will there be file transfer in Gabble too? A simpler mechanism for > cases like Read's PDF sharing should increase reliability. Yeah the plan is to implement FT in Gabble too using Jingle (so, using p2p connections) but that needs some refactoring in Gabble's jingle code. > Which Tube types and CMs do (or soon will) support Out Of Band (direct > TCP, not base64 over XML over the server)? http://telepathy.freedesktop.org/wiki/Tubes contains a good overview of the current state. Once Jingle's code will be refactored in Gabble, we could use it to implement p2p connections for stream tubes. There are still some issues in current Jingle XMPP protocol but I think Rob made good progress on this at the XMPP summit this week. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar mtg minutes, 24th July 2008
Le jeudi 24 juillet 2008 à 21:59 +0200, Tomeu Vizoso a écrit : > Hi, > > these are the minutes of today's sugar developer meeting. Please check > the minutes and complete what I may have missed. > > http://sugarlabs.org/go/DevelopmentTeam/Meetings#Thursday_July_24_2008_-_17.00_.28UTC.29 Hi guys, I read the backlog of yesterday meeting and can clarify some points to you. As said, most of the work was done in Gadget. That's a lot of work as it involves changes/work in a lot of different areas : XMPP protocol, the gadget component itself, Gabble, PS and Sugar. Things are starting to be in a good shape and I think we'll have something ready for wider testing pretty soon. See [1] for an overview of things missing and links to some tickets. I don't think Gadget will be ready for inclusion in 8.2 but I'm pretty confident to have it ready for merging at the beginning of the 9.1 cycle and so be able to properly test and debug it during the whole cycle. For 8.2, the main changes in collaboration are : - The upgrade of telepathy-glib, telepathy-gabble and telepathy-salut to newest releases fixing lot of various bugs (not necessarily collab related but fixing at least #6658 and #6647). - Various sugar-presence-service fixes and improvements (see PS's NEWS file) About file transfer. There is currently an intern working on the new FT spec and its implementation in Salut. So we should hopefully have something working at the end of this summer. Once the spec merged, we could implement it in telepathy-synapse (the Cerebro connection manager) too. Now some replies to direct questions. 18:35:51> -does gadget and cerebro solve similar problems? 18:35:53> -I mean 18:36:04> -if we have cerebro, would gadget still be necessary? They intend to solve a similar problem (the scalability) but in 2 different cases. Gadget is a XMPP component we are developing to replace the shared roster hack. So it should solve scalability problems in server mode (XO connected to the jabber server). On the other hand, telepathy-synapse is a potential replacement of telepathy-salut that should, hopefully, increase the scalability in serverless mode (children under a tree). So, yeah, we need both. 18:41:56> +cassidy: is there anything you need from the Sugar team to accelerate Gadget's progress? It would be good to review #7543 and #7544 in order to have them ready for merge at the begin of 9.2. We should also discuss about the right way to implement #7545. Last Sugar part is the search UI. I'll open a ticket about that. 18:42:06> +I've also wanted to support metadata searches ie. activity:chat That's already implemented in Gabble and Gadget. The last missing part is the GUI. Hope that help. Of course, feel free to ask if you have any other questions. :) G. [1] http://wiki.laptop.org/go/Gadget_integration_TODO ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Le jeudi 24 juillet 2008 à 03:36 -0400, Ankur Verma a écrit : > > As per our earlier discussion, the method at present is to use > roster.py, which you are planning to remove in the next versions. Humm not really. Using the roster is and will always be a sane way to find contacts. But, as you can guess, it assumes that the contact is in your roster. Currently this is a sane assumption because of the shared roster hack. But when we'll drop it, that won't be true anymore. > As roster.py also uses Telepathy to get the nicks of XO who have > subscribed or are friends, are there any alternative functions which I > can use to fetch the list of XOs? I am ready to look more into > telepathy specs, but I am curious to know the answer. The plan with Gadget is to allow user to request random buddies (and activities) or perform search based on different criteria. As you can see on [1], currently only search based on buddy properties is implemented but we plan to add alias search soon (maybe next week if you really need it). So for now, I suggest you to use a server with the shared roster hack or manually subscribe your SMS user with a test buddy for your tests. So you could test most of the part of your app and just change it to use alias search later. G. [1] http://people.collabora.co.uk/~cassidy/spec-olpc-gadget.html#org.laptop.Telepathy.Gadget ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Le mercredi 23 juillet 2008 à 12:38 -0400, Ankur Verma a écrit : > > I can run a bash/python script upon the reception of the message with > the message parameters. This makes it flexible enough to call any > application. > Then I think you should write a Python application which connect to the jabber server, find the buddy and send him the message. As a start I suggest you to take a look on the Telepathy spec [1] and telepathy-python examples. G. [1] http://telepathy.freedesktop.org/spec.html ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Le mardi 22 juillet 2008 à 18:36 -0400, Ankur Verma a écrit : > > Message is in the format Nick_Name:Message. Though its true that > Nicknames are not unique across a school, but it is the only way to > specify XO in a user-friendly manner. > > If XO is not currently connected, a SMS autoreply will be sent > indicating XO is not present in the mesh. One of the use cases would > be when parents want to know about their child's presence in the > school considering every XO in school is connected! Ok, then I think the Telepathy based client connected to the jabber server could be a good solution. In which language is written your application? G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Le mardi 22 juillet 2008 à 09:18 -0400, Ankur Verma a écrit : > > Hi Guillaume, > > Thank you for your message. > > Though it is an external application, but its intended to be run on > server (Application has similarities with server implementation like > it runs Apache) > > > A) If that's an external application, then you have to connect > to the > jabber server as any client/XO. You'll be able to see all the > connected > XO's that are in your jabber roster. Currently we are using an > ugly hack > called "shared roster" meaning you'll see all the connected > XO's but we > plan to drop it soon. > A solution could be to use Gadget [1] but we currently don't > have API to > search for buddies based on their alias (that's probably > something > useful to have so we could consider to add one). > Another solution would be for each buddies to subscribe to > your > application (as a Friend) if they are interested about > receiving SMS > messages but that's not very convenient IMHO. > > The idea of having the API to search for buddies based on their nicks > and forwarding message to them seems good. Be aware that with this solution, you won't find the XO if he's not currently connected. How do you plan to handle such case? > One of the solution to forward message can be a XMPP message, though I > am not sure how to implement this. Can you think of any alternatives? If you use Telepathy, sending a XMPP message to the contact will be trivial. > B) A server plugin. You'll be able to use the server API (and > so be able > to know which buddies are connected, etc) but you'll be depend > on a > server implementation and your app will have to run on the > same box as > the server. > > Server API doesn't let us know about the nicks of current buddies > that are connected. As Wad meant to say, Jabber IDs are available > which are not human readable and they cannot be mapped to nicks at > present. I have no idea how plugin's API work but I guess you should be able to access to most of the server's model, including the alias. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Le mardi 22 juillet 2008 à 09:11 -0300, John Watlington a écrit : > As I mentioned earlier to Ankur in a separate email, I believe the > real problem here isn't technically how to connect to the presence > service, > but rather that the presence service offers no human-usable ID which > is guaranteed to be unique within a school. This application won't run on the XO so it doesn't have to use presence-service at all. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar-presence-service 0.81.4 released
A new release of Presence Service is available at: https://dev.laptop.org/pub/sugar/sources/sugar-presence-service/sugar-presence-service-0.81.4.tar.bz2 The "Oooops I'm late" release. Fixes: * dev.laptop.org #7451: Presence Service should start even with no interfaces up Sorry for the delay. Regards, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Le jeudi 17 juillet 2008 à 15:44 -0400, Ankur Verma a écrit : > Hello, Hi Ankur, > I am able to receive SMS text messages through a mobile phone intended > to be attached to school server. I need to forward this message to a > specific XO connected on the jabber server. At this moment, I have the > message in the format XO_name:SMS_Message. My plan is: > > 1. Get information (Unfriendly Jabber ID? or Nick?) about all the XOs > connected. As I said last time we discussed this on IRC, that depends what is your application exactly: A) If that's an external application, then you have to connect to the jabber server as any client/XO. You'll be able to see all the connected XO's that are in your jabber roster. Currently we are using an ugly hack called "shared roster" meaning you'll see all the connected XO's but we plan to drop it soon. A solution could be to use Gadget [1] but we currently don't have API to search for buddies based on their alias (that's probably something useful to have so we could consider to add one). Another solution would be for each buddies to subscribe to your application (as a Friend) if they are interested about receiving SMS messages but that's not very convenient IMHO. B) A server plugin. You'll be able to use the server API (and so be able to know which buddies are connected, etc) but you'll be depend on a server implementation and your app will have to run on the same box as the server. C) A XMPP component. That's generally how XMPP gateways work. People will have to explicitly subscribe to your component. If you choose A. then I strongly suggest you to use Telepathy (Gabble) as we already have a nice API you could use instead of dealing with XMPP directly. Hope that help. G. [1] http://wiki.laptop.org/go/Gadget ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Presence Service D-Bus API
Le lundi 14 juillet 2008 à 21:54 -0700, Bert Freudenberg a écrit : > Am 14.07.2008 um 05:48 schrieb WikiAdmin: > > > anonymous user 91.179.26.46 edited Presence Service D-Bus API > > http://wiki.laptop.org/index.php?title=Presence_Service_D-Bus_API&diff=0&oldid=137835 > > > This adds the GetBuddyByTelepathyHandle() and ListChannels() methods. > Should we document the PS version of when this was introduced? I am this anonymous user. :) GetBuddyByTelepathyHandle() was in PS since age but was forgotten on the wiki, so I added it. ListChannels() was recently added (PS 0.81.3), see #4757 for details. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [SURVEY] builders, how do you build? what do you build?
Le vendredi 27 juin 2008 à 17:23 -0400, Erik Garrison a écrit : > Developers, specifically those running build systems, > > Many of us are confused about the software flows inherent in the daily > build processes which are occuring at OLPC. I would like to conduct a > simple survey of all people building software for OLPC so that all of us > can better understand the sources of the software running on the XO and > XS without individually hassling the responsible parties every time we > have generic questions about their build processes. > > Builders, please describe your local build network: > > 0) Who are you and who do you directly work for? Guillaume Desmottes, working for Collabora Ltd. > 1) What do you build? The Telepathy Stack: telepathy-gabble, telepathy-glib, telepathy-salut, telepathy-stream-engine The Farsight Stack (used for the video-chat activity): farsight, gstreamer-plugins-farsight, libjingle and sugar-presence-service. > 2) Where does it come from? / Who directly provides you with source code? Most of the time I package mine own new releases (as I'm upstream of the presence-service, Gabble and Salut) or include a patch I just wrote to fix some issue. I also occasionally package latest stable releases of the rest of the stack when I need one new feature or I know it improves general stability. > 3) Where does the output of your build process go? / Who handles the > immediate output of your builds? Directly to Koji. > 4) Where specifically is it built? (I want server names and/or > descriptions, where security is a concern please share them with me > privately.) My builds are submitted from teach.laptop.org to Koji. > 5) What build systems do you use to build software? Please briefly > describe their operation or provide a link to documentation or source > code which does. No idea :) Hope that help, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] sugar-presence-service 0.81.2 released
Le vendredi 20 juin 2008 à 20:54 +0200, Morgan Collett a écrit : > The "Features on ice" release. > > tar: > https://dev.laptop.org/pub/sugar/sources/sugar-presence-service/sugar-presence-service-0.81.2.tar.bz2 > > Thanks for managing the release Morgan (I was in holidays last week). :) G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: Guillaume's 'activity' branch of Gadget
Le mardi 10 juin 2008 à 14:42 +0100, Dafydd Harries a écrit :
> > diff --git a/gadget/component.py b/gadget/component.py
> > index b5fc702..dd85a03 100644
> > --- a/gadget/component.py
> > +++ b/gadget/component.py
> > @@ -92,8 +92,9 @@ class Room(object):
> > def __init__(self, own_nick):
> > self.own_nick = own_nick
> > self.membership = None
> > -self.members = {}
> > +self.members = set()
> > self.properties = {}
> > +self.id = None
> >
>
> Would it be possible to just have a Room.activity property and use that to
> store members/id?
>
I'll remove the Room object and move membership management to Activity
as we discussed yesterday.
> > class GadgetService(component.Service):
> > debug = False
> > @@ -333,7 +334,7 @@ class GadgetService(component.Service):
> > def message(self, stanza):
> > type = stanza.getAttribute('type', 'normal')
> >
> > -if type in ('chat', 'groupchat'):
> > +if type in ('chat'):
> > return
>
> This doesn't do quite what you want. "()" doesn't create a tuple, "," does, so
> this is the same as "type in 'chat'", which will be true if type is a
> substring of "chat". Better to just say "==".
>
Right. Forgot about that, good catch. Fixed.
> >
> > if type == 'normal':
> > @@ -343,12 +344,17 @@ class GadgetService(component.Service):
> > return
> > elif (elem.uri == ns.ACTIVITY_PROP and
> >elem.name == 'properties'):
> > -self.message_activity_properties(stanza, elem)
> > +self.message_pre_invite_activity_properties(stanza,
> > elem)
> > return
> > elif elem.uri == ns.PUBSUB_EVENT and elem.name == 'event':
> > self.message_pubsub_notification(stanza, elem)
> > return
> >
> > +elif type == 'groupchat':
> > +for elem in stanza.elements():
> > +if elem.uri == ns.ACTIVITY_PROP and elem.name ==
> > 'properties':
> > +self.message_activity_properties(stanza, elem)
>
> You should return here. Perhaps we should dispatch messages more like we
> dispatch IQs, i.e. using a dict.
>
fixed. I added a FIXME suggestion a better dispatch system.
> > +
> > # FIXME: handle close query stanza
> > log.msg('got unhandled ')
> >
> > @@ -357,7 +363,7 @@ class GadgetService(component.Service):
> > if elem.uri == ns.MUC_USER and elem.name == 'invite':
> > self.message_muc_invite(stanza, elem)
> >
> > -def create_room(self, jid, properties):
> > +def create_room(self, jid, properties, id):
>
> Hmm, can we put the id before the properties? I think it's more aesthetically
> pleasing that way.
>
done.
> > if jid in self.mucs:
> > # We already have a room by this name.
> > return
> > @@ -366,9 +372,10 @@ class GadgetService(component.Service):
> > # join it.
> > room = Room('inspector')
> > room.properties = properties
> > +room.id = id
> > self.mucs[jid] = room
> >
> > -def message_activity_properties(self, stanza, properties_elem):
> > +def message_pre_invite_activity_properties(self, stanza,
> > properties_elem):
> > # XXX Restrictions on from address?
> >
> > try:
> > @@ -384,7 +391,7 @@ class GadgetService(component.Service):
> > if not (properties and activity and room_jid):
> > return
> >
> > -self.create_room(room_jid, properties)
> > +self.create_room(room_jid, properties, activity)
>
> Perhaps we should rename 'activity' to 'activity_id' for clarity.
>
done.
> > def message_muc_invite(self, stanza, invite):
> > to = stanza.getAttribute('to')
> > @@ -502,17 +509,54 @@ class GadgetService(component.Service):
> > # Presence for our in-room self; we've finished joining the
> > # room.
> > room.membership = 'joined'
> > +
> > +# activities are created and added to the model when the
> > +# inspector actually joined the muc.
>
> English nitpicks: Your tenses don't agree here. "are created" ... "joined".
> s/joined/join/. If you use a full stop, you should also capitalise the first
> letter.
>
fixed.
> > +# If we'll do it before, we won't be able to properly track
> > +# activity's properties and members.
>
> I don't understand this comment.
>
Humm me neither actually :) Removed.
> > +activity = self.model.activity_add(room.id, room_jid,
> > +room.properties)
> > +
> > +# Activity and Room now share the same set() object
> > +activity.members = room.members
> > return
> >
> > +item = xpath_query('/p
Re: [sugar] journal object transfer for 8.2
Le lundi 09 juin 2008 à 16:12 -0400, Michael Stone a écrit : > Tomeu, > > > have heard occasional requests to implement the sending and sharing of > > journal entries. > > It's a desirable feature but, from my perspective, it's much lower in > immediate priority than work which brings the sugar UI revision into a > releasable condition and which "polish" the existing work by closing > several of the 379 tickets assigned to component 'sugar': > > > http://dev.laptop.org/query?status=assigned&status=new&status=reopened&component=sugar&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component > > > So the questions are: is this a feature we should deliver for the 8.2 > > release? > > In my opinion, "no". > > Do you think differently? The new (work in progress) Telepathy file transfer specification should be able to nicely implement object transfer. But I doubt we'll have an implementation ready for 8.2. Could be a cool feature for the next release cycle though. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: Daf's view branch
Le jeudi 05 juin 2008 à 12:58 +0200, Guillaume Desmottes a écrit : > Le jeudi 05 juin 2008 à 12:40 +0200, Guillaume Desmottes a écrit : > > +class ActivityViewHandler(object): > > This class should have member_added and member_removed methods as its > > dummy implementation in test_model. A FIXME would be enough for now. > > We should probably have a properties_changed method too. > > Btw, activity_found should also send activity properties and > participants. > I wrote protocol for activity added/removed: > http://wiki.laptop.org/go/XMPP_Component_Protocol#Added > ... and each time we send buddies jid (in as participants and in announcements) Gadget should include buddy properties if the user doesn't already have an view with this buddy (as then he already knows about his properties). G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: Daf's view branch
Le jeudi 05 juin 2008 à 12:40 +0200, Guillaume Desmottes a écrit : > +class ActivityViewHandler(object): > This class should have member_added and member_removed methods as its > dummy implementation in test_model. A FIXME would be enough for now. > We should probably have a properties_changed method too. Btw, activity_found should also send activity properties and participants. I wrote protocol for activity added/removed: http://wiki.laptop.org/go/XMPP_Component_Protocol#Added G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] review: Daf's view branch
Just few comments:
+class ActivityViewHandler(object):
This class should have member_added and member_removed methods as its
dummy implementation in test_model. A FIXME would be enough for now.
We should probably have a properties_changed method too.
+self.activity_views = {}
A comment explaining the type of the keys and values would be good.
I think you're right, we could stop to support multi actions in queries
(as you already dropped them in views)
In test_model.py you have some: #self.assertEquals(42, context) that
could be removed.
Same for #self.assertEquals([activity2], found_log.
What's your test.py hack? Didn't we already merge the one making error
message more informative?
Except that looks good. I like how you refactored query/view parsing
code and the general design of views.
G.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Refactor invites for 1-1 Chat (#6298)
Le mercredi 04 juin 2008 à 17:08 +0200, Morgan Collett a écrit : > The main code to review is at: > http://dev.laptop.org/git?p=users/morgan/sugar;a=shortlog;h=6298 (3 > most recent patches). As bundle_id is passed to both constructor, you could move it to BaseInvite.__init__ Didn't read code carefully but InviteButton and InvitePalette still contain lot of: if shared: ... else: # private Maybe it would be worth to abstract these 2 classes too if possible? G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Le mardi 03 juin 2008 à 14:33 -0400, Polychronis Ypodimatopoulos a
écrit :
> Guillaume Desmottes wrote:
> > Search queries will return a {Buddy,Activity}View object. This object
> > will have a Get{Buddies,Activities} method to retrieve the result of the
> > search, a "Changed" (or Added/Removed) signal to track changes and a
> > Closed method when user is not interested anymore by the result of the
> > search.
> >
> > Does it make sense to you? Suggestions are welcome.
> > I'll update http://wiki.laptop.org/go/Presence_Service_D-Bus_API with my
> > changes.
> >
> I would suggest not returning objects on any of the dbus calls; this
> makes it harder to go through and debug the code both in the presence
> service and telepathy. We should try to keep it as simple as possible
> wrt the messages that are exchanged between the presence service and
> telepathy. The presence service currently offers a nice abstraction of
> how telepathy works, but this abstraction is hindered by the fact the
> the presence service returns telepathy objects.
PS won't return Telepathy objects but buddies and activities as it
always did. The {Buddy,Activity}Views returned in Telepathy won't be the
same as the one returned by PS. In the TP case, views contains handles,
in the PS case they contains buddy and activity objects (as when
GetBuddies or GetActivities methods are called on PS).
G.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Le mardi 03 juin 2008 à 12:34 +0200, Marco Pesenti Gritti a écrit :
> > For now I'm focusing on PS API. If someone wants to work on the GUI side
> > when they are done that would be great.
>
> What kind of API are you planning for the PS? Trying to understand how
> much work it will be to hook it up into the UI.
Probably something similar than the Gabble one. See
http://people.collabora.co.uk/~cassidy/spec-olpc-gadget.html#org.laptop.Telepathy.Gadget
Search queries will return a {Buddy,Activity}View object. This object
will have a Get{Buddies,Activities} method to retrieve the result of the
search, a "Changed" (or Added/Removed) signal to track changes and a
Closed method when user is not interested anymore by the result of the
search.
Does it make sense to you? Suggestions are welcome.
I'll update http://wiki.laptop.org/go/Presence_Service_D-Bus_API with my
changes.
G.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Le mardi 03 juin 2008 à 12:11 +0200, Marco Pesenti Gritti a écrit : > On Tue, Jun 3, 2008 at 11:59 AM, Morgan Collett > <[EMAIL PROTECTED]> wrote: > > Gadget is a server side component for the jabber server that will > > address the scalability issues by showing presence for only a subset > > of those on the server. It will therefore allow many more on the > > server at once. > > > > There will be PS and mesh view changes required - see Guillaume's > > recent mail(s) to [EMAIL PROTECTED] > > When is the backend planned to land? > Well, this involves work in a lot of modules: - the gadget component itself - telepathy-gabble: new API's for search/random and protocol to talk to Gadget - sugar-presence-service: new API's using Gabble's search features - sugar-toolkit: convenient wrapper for PS new API's - sugar: GUI to perform searches, etc Currently, most of the work has been done in Gadget and Gabble and I recently started PS changes. > What happens if we land only the backend without the search features? > Do we only see a random number of buddies? Yes, if sugar request these buddies (shouldn't be more complicated than a D-Bus method call on PS). I think that's a good idea to focus on random queries for now as it doesn't require new UI and sugar changes should be pretty simple. That's not a new feature from user pov but could allow us to deploy a public jabber server without the shared roster hack and see how it scales. > How does it work from the UI code perspective? We set a filter and > buddies which doesn't match the search disappear (as if they have had > left)? Don't know. I'm not a GUI expert, we are open to any suggestion. > Is Collabora planning to do the UI side of it? > For now I'm focusing on PS API. If someone wants to work on the GUI side when they are done that would be great. > Sorry, lots of questions :) np :) G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Gadget's feature integration in Sugar
Hi, Daf and I are making good progress on Gadget, so that's a good time to start to think about its integration in Sugar. Basically, Gadget is a XMPP server component that should solve our current scalability issues and drop the ugly "shared roster" hack. I invite you to take a look on the "Use Cases" and "Design Goals" sections of http://wiki.laptop.org/go/XMPP_Component_Protocol to have a better idea of what Gadget is and which problem it tries to solve. Here is a list of few points that should be discussed about their sugar integration. - We need GUI to perform buddy searches. Buddies can be searched using their properties (color, key, jid). - We also need GUI to perform Activity searches. Activities can be searched using their properties (color, name, type, tags) or their participants (based on their jid). I guess these searches should be done directly from the mesh view. How should we expose the different type of search in the GUI? - As we intent to drop the shared buddy server hack, people won't see all the buddies connected on the server anymore. They'll see their friends, the result of the active searches and a maximum of $N random buddies and $N' random activities. Should we hardcode the value of this $N? Make it configurable from the GUI? From sugar-control-panel (and so stored in a config file)? Adapt it according the number of buddies already displayed on the mesh view? Once a search is performed, user will automatically received change notifications from the result of the search until the "search result" (called "view" in Gadget) is closed. Do we want to allow users to keep more than one search result a time? If yes, we need GUI to close views. If not, I'll guess that each new search will close the previous one. For privacy reasons, user can choose to not be indexed by gadget (so he can't be found by other users). Do we want to expose this in the GUI? As that's not a really common use case, I guess an option modifiable using sugar-control-panel should be enough. Suggestions are more than welcome. Thanks, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] ANNOUNCE: sugar-presence-service 0.81.1 released
The "I'm full of Glucose" release. tar: https://dev.laptop.org/pub/sugar/sources/sugar-presence-service/sugar-presence-service-0.81.1.tar.bz2 - No code change since 0.79.3, the point of this release is to sync version number with Sucrose. Regards, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: gadget presence branch
Le jeudi 15 mai 2008 à 21:57 +0100, Dafydd Harries a écrit :
> > +# FIXME: we should send presence to buddies subscribed to gadget.
> > How?
> > if self.debug:
> > self.xmlstream.setDispatchFn(self.onElement)
> >
>
> I'm guessing your roster branch answers this question.
>
yep
> > @@ -235,6 +236,9 @@ class GadgetService(component.Service):
> > def presence(self, stanza):
> > type = stanza.getAttribute('type')
> > from_ = stanza.getAttribute('from')
> > +# remove the ressource
> > +jid = from_.split('/')[0]
> > +to = stanza.getAttribute('to')
> >
> > if from_ is None:
> > return
>
> Twisted has code for handling JIDs; let's use that.
>
> >>> from twisted.words.protocols.jabber import jid
> >>> jid.JID('[EMAIL PROTECTED]/baz').userhost()
> '[EMAIL PROTECTED]'
>
Good catch fixed.
> Looks great otherwise. Please merge!
>
merged.
Thanks for the review.
G.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: gadget buddy search code
Le jeudi 15 mai 2008 à 20:33 +0100, Dafydd Harries a écrit :
> Ar 15/05/2008 am 15:04, ysgrifennodd Guillaume Desmottes:
> > Le mercredi 14 mai 2008 à 22:52 +0100, Dafydd Harries a écrit :
> > > > +# FIXME: add more types
> > > > +type_to_str = {str: 'str'}
> > > > +str_to_type = {'str': str}
> > > > +
> > >
> > > We should check which types the buddy/activity interfaces support for
> > > properties, and test each of those types.
> > >
> >
> > Gabble supports the following types: str, bytes, int, uint and bool.
> >
> > I started to write tests for parse_properties and properties_to_xml but
> > I encountered a problem.
> > Currently we store properties in a dict like {'key': (type, 'value')} as
> > {'color': (str, 'red')} for example.
> >
> > But how should I store an uint as Python doesn't have an uint type?
> > Using dbus type? Or we could store the string representation of the type
> > instead of a python type ('str' instead of str).
> >
> > And how should we store the value? Using the type-converted value (so
> > the numerical value for int/uint, True/False for bool, etc) or the
> > string version?
>
> The only thing the value representation matters for is searching. Storing them
> as strings should be ok as long as there is only one string representation for
> each value.
>
> I'm not sure that the representation of the type matters. We should do
> whatever is simplest. I suspect that might be storing the types as strings,
> but I'm not sure.
>
As you said, the only purpose of these properties is for searching so
storing both values and types as string is the easiest solution.
I changed that and added support to uint, bool and bytes types.
> > +self.log("Ignore activity properties message from %s
> > containing an invalid property"
>
> This should be in the present tense ("Ignoring...") or the past tense
> ("Ignored..."). I think I prefer the former.
>
fixed.
> Sure. But:
>
> +class BuddyIqTest5(TestCase):
> +"""buddy multi query with two results"""
>
> +class BuddyIqTest5(TestCase):
> +"""buddy query with an invalid property"""
>
> Let's rename the second one to BuddyIqInvalidPropertyTest or something like
> that.
>
done.
> Otherwise, go ahead and merge.
>
merged, thanks for your comments
G.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: gadget buddy search code
Le jeudi 15 mai 2008 à 21:41 +0100, Dafydd Harries a écrit : > Ar 15/05/2008 am 20:33, ysgrifennodd Dafydd Harries: > > Otherwise, go ahead and merge. > > A couple of other nitpicks: > both are fixed. > > +class ParsePropertiesTest(TrialTestCase): > ... > > +class PropertiesToXmlTest(TrialTestCase): > > These don't use any Trial features, so could just be unittest.TestCases. > > > +try: > > +parse_properties(properties) > > +except PropertyTypeError, e: > > +pass > > +else: > > +assert False, "should not be reached" > > self.assertRaises is the idiomatic way to do this. > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: gadget buddy search code
Le jeudi 15 mai 2008 à 21:38 +0100, Dafydd Harries a écrit : > Ar 15/05/2008 am 20:33, ysgrifennodd Dafydd Harries: > > +class BuddyIqTest5(TestCase): > > +"""buddy multi query with two results""" > > > > +class BuddyIqTest5(TestCase): > > +"""buddy query with an invalid property""" > > > > Let's rename the second one to BuddyIqInvalidPropertyTest or something like > > that. > > Same applies to ActivityIqTest4. > fixed. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: gadget buddy search code
Le mercredi 14 mai 2008 à 22:52 +0100, Dafydd Harries a écrit :
> > +# FIXME: add more types
> > +type_to_str = {str: 'str'}
> > +str_to_type = {'str': str}
> > +
>
> We should check which types the buddy/activity interfaces support for
> properties, and test each of those types.
>
Gabble supports the following types: str, bytes, int, uint and bool.
I started to write tests for parse_properties and properties_to_xml but
I encountered a problem.
Currently we store properties in a dict like {'key': (type, 'value')} as
{'color': (str, 'red')} for example.
But how should I store an uint as Python doesn't have an uint type?
Using dbus type? Or we could store the string representation of the type
instead of a python type ('str' instead of str).
And how should we store the value? Using the type-converted value (so
the numerical value for int/uint, True/False for bool, etc) or the
string version?
> > @@ -46,10 +50,25 @@ def parse_properties(elem):
> > if type is None or name is None or value is None:
> > continue
> >
> > -properties[name] = (type, value)
> > +try:
> > +properties[name] = (str_to_type[type], value)
> > +except KeyError:
> > +continue
>
> We shouldn't just ignore failed conversions. We should throw an error, and
> make the caller return an error to the client. Perhaps the exception class
> would have some convenience code for generating the error stanza.
>
Good idea. Implemented.
> > +def properties_to_xml(properties, elem):
> > +for key, (type, value) in properties.iteritems():
> > +try:
> > +str_type = type_to_str[type]
> > +except KeyError:
> > +continue
> > +
> > +property = elem.addElement((None, 'property'))
> > +property['type'] = str_type
> > +property['name'] = key
> > +property.addContent(value)
> > +
> > class Room(object):
> > def __init__(self, own_nick):
> > self.own_nick = own_nick
>
> Again, we shouldn't silently ignore errors. This lookup should never fail,
> because it would mean that we've stored invalid property data in the model.
>
Right, fixed.
> > @@ -118,19 +137,100 @@ class GadgetService(component.Service):
> >
> > def iq_buddy_query(self, stanza):
> > result = make_iq_result(stanza)
> > +_query = stanza.firstChildElement()
> > query = result.firstChildElement()
> >
> > -for buddy in self.model.buddy_search({}):
> > +results = set()
> > +if len(_query.children) == 0:
> > +# no buddy childs. We want all the buddies
> > +results.update(self.model.buddy_search({}))
>
> s/childs/children/.
>
> Please put blank lines before blocks, for consistency.
>
> Can we say "if _query.children:" instead? It's more idiomatic.
>
fixed.
> > +
> > +for elem in _query.children:
>
> I'm not sure we should support answering multiple queries in one IQ. I'm not
> sure if it does any harm, but I haven't seen other XMPP protocols allow it.
>
Don't know, I implemented the protocol described on
http://wiki.laptop.org/go/XMPP_Component_Protocol
> > +if elem.name != 'buddy':
> > +continue
> > +found = None
> > +
> > +# jid search
> > +try:
> > +tmp = set([self.model.buddy_by_id(elem['jid'])])
> > +if found is None:
> > +found = tmp
> > +else:
> > +found.intersection_update(tmp)
> > +except KeyError:
> > +pass
>
> The "if found is None:" seems strange, becuase "found" should always be None
> at this point in the code.
>
fixed.
> There's too much code inside the try: clause. What lookup are we expecting
> might fail? If it's the elem['jid'] lookup, I'd prefer this approach:
>
buddy_by_id can raise the exception too. I made this code clearer.
> jid = elem.getAttribute('jid')
>
> if jid is None:
> continue
>
> > +
> > +# properties search
> > +for e in elem.children:
> > +if e.name == 'properties' and e.uri == ns.BUDDY_PROP:
> > +props = parse_properties(e)
> > +tmp = set(self.model.buddy_search(props))
> > +if found is None:
> > +found = tmp
> > +else:
> > +found.intersection_update(tmp)
>
> Can we rename "tmp" to "buddies" or "results"?
>
done
> > +
> > +if found is not None:
> > +results.update(found)
> > +
> > +for buddy in results:
> > buddy_elem = query.addElement((ns.BUDDY, 'buddy'))
> > buddy_elem['jid'] = buddy.jid
> > +properties = buddy_elem.addElement((ns.BUDDY_PROP,
> > 'properties'))
> > +properties_to_xml(buddy.properties, properties)
> >
> > return res
Re: [sugar] Volunteers/help for sugar/cerebro integration
Le mercredi 14 mai 2008 à 12:23 -0400, Polychronis Ypodimatopoulos a écrit : > The integration can be done in either of these two ways: > > 1) Create a new telepathy connection manager that will act as interface > between telepathy and cerebro. Some preliminary work already done by > Michael Stone [2]. > This way is a lot much saner. If you implement a new presence-service, XO won't be able to connect to a school server (using jabber) anymore. Furthermore, activities use also the Telepathy API (for tubes and chat mainly) so you'll need it anyway. Please don't break the abstraction layer. G. > 2) Add the necessary callbacks in cerebro that will allow it to act as > presence service to sugar directly [3]. Cerebro provides the necessary > functionality, but lacks several dbus callbacks. > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Push get_buddy from Connect into sugar.presence (#6473)
Le mercredi 14 mai 2008 à 15:58 +0200, Morgan Collett a écrit : > In case it is a channel with channel specific handles... > > if self.self_handle == cs_handle: > # It's me, just get my global handle > handle = self._conn.GetSelfHandle() > > We either need to call GetSelfHandle regardless of knowing whether the > group has channel specific handles, or we need to call GetGroupFlags > regardless of whether it is my handle. Is either of those less costly? > Right, I forgot self.self_handle could be channel specific too. My bad. > > I'm wondering if it shouldn't be better to override watch_participants > > (or add a new similar mechanism) returning directly buddies instead of > > handles. Would it be possible/worth to completely hide handles and > > always use buddies from the activity Pov? > > There's a chance that some will want to use telepathy calls directly > in the activity, in case we end up oversimplifying the collaboration > API. You could make the same argument about the bus names... but if > you think it's a good idea, provide a patch we can review :) I don't know really, was just a random thought. I guess your patch is good for now. We'll still be able to improve this API later if needed. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC priorities for Sugar in the August release
Le mercredi 14 mai 2008 à 11:48 +0200, Tomeu Vizoso a écrit : > * Groups, models for groups (Peru, Hernan) > > Is this groups in Sugar? Do we have some kind of requirements? There are some discussions about groups here: https://dev.laptop.org/ticket/4043 G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Push get_buddy from Connect into sugar.presence (#6473)
Le mardi 13 mai 2008 à 17:03 +0200, Morgan Collett a écrit : > This subclasses TubeConnection to make a version (SugarTubeConnection) > that can resolve a handle to a Buddy. > > Patches are for sugar(.presence) and Connect. +handle = self._conn.GetSelfHandle() Why call the GetSelfHandle() D-Bus method as you already have the handle? handle = self.self_handle should be enough +# deal with failure to get the handle owner +if handle == 0: +return None I think this should always be done, not only in the else branch. I'm wondering if it shouldn't be better to override watch_participants (or add a new similar mechanism) returning directly buddies instead of handles. Would it be possible/worth to completely hide handles and always use buddies from the activity Pov? G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Shared Terminal Idea
Le lundi 12 mai 2008 à 13:25 -0400, Benjamin M. Schwartz a écrit : > I think shared Terminal would be very cool. A lot of other people seem to > think so too. It would be a fun way to learn command-line stuff, by > sharing a prompt with a remote friend. > Definitely. Shared terminal could be a killer feature. I'd like to see something similar in GNOME using gnome-terminal and Empathy. Most of the work could probably be reused. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] f8+ sugar-jhbuild telepathy-gabble problem
Le vendredi 09 mai 2008 à 12:34 +0200, Marco Pesenti Gritti a écrit : > On Fri, May 9, 2008 at 12:07 PM, Guillaume Desmottes > <[EMAIL PROTECTED]> wrote: > > > > Thanks to the help of Frédéric Peters (jhbuild upstream maintainer) I > > found the reason of this. > > I pushed a fix to > > https://dev.laptop.org/git?p=users/guillaume/sugar-jhbuild;a=shortlog;h=fix-fedora8 > > > > Waiting review from Marco before merging it to HEAD. > > Please push. In general everyone with access to the sugar-jhbuild > module should feel free to push changes to sysdeps (just ask in the > case that you are unsure). > pushed. Martin: could you retry to build telepathy-gabble with an updated sugar-jhbuild please? G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] f8+ sugar-jhbuild telepathy-gabble problem
Le vendredi 09 mai 2008 à 11:47 +0200, Guillaume Desmottes a écrit : > Le jeudi 08 mai 2008 à 14:10 +0100, Martin Dengler a écrit : > > Hi sugar@, > > > > I'm having a problem with sugar-jhbuild that's somewhat new: > > loudmouth is 1.2.3 on a F8 + updates, but sugar-jhbuild now requires > > it to be 1.3.2: > > http://cree.xades.com/~martin/src/xo-sugar-jhbuild/telepathy-gabble.html#configure > > > That's weird, loudmouth is supposed to be built in sugar-jhbuild as a > dependency of telepathy-gabble. > > I tested on my box and loudmouth isn't build by sugar-jhbuild. You can > easily check that running: > ./sugar-jhbuild list | grep loudmouth > > I'm investigating why. Thanks to the help of Frédéric Peters (jhbuild upstream maintainer) I found the reason of this. I pushed a fix to https://dev.laptop.org/git?p=users/guillaume/sugar-jhbuild;a=shortlog;h=fix-fedora8 Waiting review from Marco before merging it to HEAD. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] f8+ sugar-jhbuild telepathy-gabble problem
Le jeudi 08 mai 2008 à 14:10 +0100, Martin Dengler a écrit : > Hi sugar@, > > I'm having a problem with sugar-jhbuild that's somewhat new: > loudmouth is 1.2.3 on a F8 + updates, but sugar-jhbuild now requires > it to be 1.3.2: > http://cree.xades.com/~martin/src/xo-sugar-jhbuild/telepathy-gabble.html#configure That's weird, loudmouth is supposed to be built in sugar-jhbuild as a dependency of telepathy-gabble. I tested on my box and loudmouth isn't build by sugar-jhbuild. You can easily check that running: ./sugar-jhbuild list | grep loudmouth I'm investigating why. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] 1-1 Chat (non-Sugar Jabber clients #6298)
Le mercredi 07 mai 2008 à 10:03 +0200, Morgan Collett a écrit : > I've attached patches for Sugar and Chat that handle incoming XMPP 1-1 > connections, from a non-Sugar Jabber client. > > It's a bit of a proof of concept, because although it works there are > some issues that need improving - so please review and comment... I'm > looking for input from Marco/Tomeu, Eben, Daf/Guillaume... > > * From a Jabber client registered on the Jabber server I initiate a > chat with the Buddy. > * Presence Service sends private-invitation to sugar.presence and then > to the shell. > * The signal has the Telepathy channel for this 1-1 connection which > needs to get to Chat. > * I'm (ab)using activityfactory.create_with_uri to launch Chat with > the Telepathy channel in the metadata. > * That makes Chat launch magically. That violates the requirement that > the user initiate the activity. > * I'm using json (probably badly?) to pass the two strings identifying > the Telepathy channel. > * The first message from the non-Sugar client (which initiates the > connection) gets dropped somewhere, and only subsequent messages get > through to Chat. I guess you should be able to got this message using channel[CHANNEL_TYPE_TEXT].ListPendingMessages() See http://telepathy.freedesktop.org/spec.html#org.freedesktop.Telepathy.Channel.Type.Text We should probably call it in set_received_callback() Btw, it seems we never acked received messages. Is that intentional? According the spec each message should be acked when they are displayed. > * Presence Service sends private-invitation on both CHANNEL_TYPE_TEXT > and CHANNEL_TYPE_STREAMED_MEDIA (which should go to video chat > eventually). When we have agreed on how to handle Chat I'll figure out > how to differentiate them and send the media one to video chat. You can find the type of the channel by calling GetChannelType() on the channel object. Or maybe we could just add the channel type in the signal. > It has also been suggested that the incoming chat appear as an > invitation. I had a look but couldn't yet figure out how best to > represent something that is not an activity, does not have colors, and > is not a room on the server. Input appreciated. > I agree, displaying an incoming chat as an invitation is much more saner than automatically launch Chat. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] E-mail, XMPP, and non-Sugar identities
Le mercredi 30 avril 2008 à 17:57 -0400, Benjamin M. Schwartz a écrit : > It seems that many people would prefer if non-Sugar users could be > integrated into the interface. For example, it has been suggested that > Sugar should provide a mechanism for enabling text chat with non-Sugar > Jabber users. Clearly, they cannot participate in arbitrary Sugar > activities, but perhaps they can send text or files, and stream audio or > video. I believe that the Telepathy developers have thought a great deal > about integrating with standard Jabber when possible. > The communication layer (XMPP and XMPP link local (used by Salut)) is ready for that. For example, last week I established an audio/video call between my XO running the video-chat activity and my desktop running Empathy. Most of the work is in Sugar: - Chat should properly handle 1-1 chats and not activity mucs (#6298) - Sugar should offer a way to add not OLPC Friends (by entering their JID) - Sugar should also ask to the user if he accepts a subscription request - We should display not OLPC buddies (== without key) in the mesh view. Et voilà! We'll be able to communicate with not OLPC Jabber and XMPP link local users. For bonus point, we could even optionally use other Telepathy connection managers (trivial presence-service work) and gain support of others protocols for free. As MSN (telepathy-butterfly), IRC (telepathy-idle), SIP (telepathy-sofiasip) and all the protocols supported by Pidgin (telepathy-haze). That's the whole point of our Telepathy abstraction. You implement your UI once and gain support of a lot of protocols just by installing new connection managers. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] request for help - how to restart gabble ?
Le samedi 12 avril 2008 à 15:18 -0400, Chris Ball a écrit : > Hi Mikus, > >> Is re-starting Sugar (ctl-alt-erase) the only "approved" way to >> re-start gabble, or are there commands which would do it without >> having to re-start the currently running Sugar ? > > I believe the gabble/salut logic is triggered by the network interfaces > going up, so clicking on your AP again in the mesh view (to force a > reconnect) should trigger it. Yeah you can do that. The other way is just to wait a bit as Gabble will constantly try to connect to the jabber server using an exponential backoff (which is limited to ~ 5 minutes IIRC). G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
Le mardi 25 mars 2008 à 16:02 -0400, Benjamin M. Schwartz a écrit : > This works, and will work for the proposed case. For the future, I see > file transfer as precisely the sort of thing that should be handled > internally to Telepathy. Perhaps Telepathy should implement XEP-0234 > (file transfer)[2] or even XEP-0214 (file sharing)[3]. > We have a draft of spec for file transfer (but it will be probably modified) and a Salut branch implementing it. So that's definitely something that could be done at some point. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] The futur of the mesh view
Hi, We recently started the design of a futur XMPP server component. It should solve the scalability problems with current implementation and will avoid to display hundreds of buddies and activities on the mesh view, making it unusable. We'd like to know what are the exact plans from an use cases point of view and discuss few points about that. - Friends will always be displayed in the mesh view when they are online. Do we want to show: them, them and their current activity, them surrounded by all their activities, their current activity surrounded by everyone in that activity? - Do we want any extra information for the friends screen, for example your friend surrounded by all of his activities? - Users will be able to search for buddies (using search keys as color, alias, name, email, etc.). The result of this search will be displayed on the mesh view. Same question, what about their activities? Should we display them too? - Kids will also perform activity searches (using keys as name, type, color, maybe participants?). Here again, the result will appear on the mesh view. Do we plan to display buddies who are in these activities too? - Which kind of search method will be proposed in the GUI? Should we support different options in our search protocol (as substring, equality, case insensitive,...)? How do we plan to distinguish a search for users from a search for activities? Should we show all matching activities and all matching buddies? - Currently each activity has an globally unique identifier. This ID make sense in Sugar as it have to identify shared and not shared activities. But it's redundant in the PS and CM's (Gabble and Salut) as each shared activity can also be identified using its muc's jid. Would it be possible to make activity ID's *locally* unique? So we could simplify/sanitize our XMPP protocol and Telepathy API. It seems activity ID's are used when restoring shared instance but it's not clear if it should assume these ID's are global or not. You can find more explanations about the current stage of our investigations on http://wiki.laptop.org/go/XMPP_Extensions#Use_Cases and http://wiki.laptop.org/go/XMPP_Component_Protocol . Please tell us if you see wrong assumptions or missing use cases. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] new tubes API
Hi, Since yesterday, sugar jhbuild uses Gabble and Salut trial 3 branches. Theses branches implement the latest spec tubes and so provide a new API for activities. See http://telepathy.freedesktop.org/spec.html#org.freedesktop.Telepathy.Channel.Type.Tubes Changes are mostly trivial for D-Bus tubes and CM should be backward compatible. Basically: OfferTube -> OfferDBusTube AcceptTube -> AcceptDBusTube GetDBusServerAddress -> GetDBusTubeAddress Sugar, Connect, Write, Memorize and Web have been updated to use this new API. If I forgot an activity please tell me and I'll write a patch for it. Futur trial-3 builds should be sure to ship the new version of these modules. Of course, please tell us if you find any regression due to these changes. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Tubes message dropping
Le samedi 21 juillet 2007 à 21:02 +0100, Simon McVittie a écrit : > On Sat, 21 Jul 2007 at 13:50:27 +0200, J.M. Maurer wrote: > > To the Tube guys: > > > > Do you drop messages on your XMPP server? An AbiCollab packet that > > contains an image never gets sent over, resulting in documents getting > > out of sync (in fact, the PS seems to disconnect the buddy altogether > > from the Write session). > > Without reading the source for Gabble: It's possible that (a) we don't > fragment large Tubes messages into multiple XMPP-level messages, and (b) the > XMPP server we're using fails on large messages. I'd have to check the > source and XEPs to be sure. If this is the case, a workaround would be to > avoid sending very large single messages in user apps, and the correct fix > would be to fragment the D-Bus message into multiple XMPP messages in Gabble. > > Guillaume: you touched it last, I think. Are we likely to have this bug? > Right, currently we don't fragment large messages and make the assumption "one IBB message == one tube message". So, it's probably the server who reject too big IBB stanzas. We could modify our IBB implementation to fragment big stanzas but that would make the code sensibly more complicated. Furthermore I'm not sure the server will allow us to send N MAX_SIZE stanzas consecutively. IBB is really not designed to send big datas (XEP suggests 4096 bytes as max payload size). A quick workaround could be to raise the allowed stanza max size in the server config. Oth, I can't see how to easily implement MUC D-Bus tubes without using IBB, so maybe at some point we'll have to implement messages fragmentations anyway. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
