[sugar] Requirements for activity and buddy properties needed

[Dan Williams]

On Mon, 2007-08-13 at 21:52 +0100, Simon McVittie wrote:
> On Wed, 08 Aug 2007 at 03:16:22 +0100, Simon McVittie wrote:
> > On Tue, 07 Aug 2007 at 19:44:30 -0400, Eben Eliason wrote:
> > > Regarding tags, I won't get into details here, but we also have ideas around
> > > tags which require each tag to have an associated identity (unique ID for a
> > > buddy and a color pair) for use in displaying the tags. If we do follow this
> > > approach, we'll need a more complex data structure for the tag list.
> > 
> > It's looking as though tags can't happen for Trial 3 or FRS; we certainly can't
> > implement "a more complex data structure" without knowing in advance what it
> > *is*, and the feature freeze date is rumoured to be Monday.
> 
> So. If we do have time to get "tag propagation across the network" into Trial 3:
> 
> * Is it acceptable for them to just be a single Unicode string that anyone can
>   change, for the purposes of all the code apart from the UI?
>   (which can do what it likes with that string, e.g. treating it as
>   comma-separated)

If doing this makes it work for Trial-3, then lets do it this way.

> * Is there something more complex we should be trying to implement by
>   preference? For instance:

Eventually, yes.  But if it's going to take a lot of work, lets get
rudimentary tags in first.

>   - list of strings, setting them has "union" semantics
>   - list of strings per user, you can tell who set what, you can't get
>     rid of the tags someone else set (in which case: do the tags that they
>     set go away when they leave the activity, or not?)

I think this was more like the idea, where we could identify which buddy
set what tag, so the UI could display the tag in that buddy's colors.
That means at least passing around the tag and possibly the JID with the
tag so it could be matched to a buddy.

>   - list of structs containing (insert wishlist here)
> 
> * If there are more complex things that you'd like, but we only have
>   time to do something simpler, how simple can we go and still have you
>   consider it to be better than nothing?

A single "shared" string property sounds like the best bet for the
moment, given the time to implement.

Dan