[sugar] Gadget's feature integration in Sugar

Guillaume Desmottes guillaume.desmottes
Mon Jun 2 07:41:58 EDT 2008


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.





More information about the Sugar-devel mailing list