[sugar] The futur of the mesh view

Guillaume Desmottes guillaume.desmottes at collabora.co.uk
Tue Dec 4 11:34:56 EST 2007


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.



More information about the Sugar mailing list