[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
[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] 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] [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
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. 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] 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] 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. marcopg 18:35:51 -does gadget and cerebro solve similar problems? marcopg 18:35:53 -I mean marcopg 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. bemasc 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. eben 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 à 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] 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 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 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] 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_APIdiff=0oldid=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 message')
@@ -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('/presence/[EMAIL PROTECTED]%s]/item' %
ns.MUC_USER,
+stanza)
+if not item or item[0].getAttribute('jid') is None:
+log.msg(full jid of %s missing. Can't update activity
[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] 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
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] [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 à 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
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
[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
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 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 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] 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 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] 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] 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 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] 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 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] [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] 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
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
