> I think that the addition of a new property in the activity.info file
> would be logical here.  Make it an integer indicating the maximum
> number of supported participants.  "Unshared" activities would report
> '1', activities like video chat (with technical limitations) or chess
> (with obvious player limits) might specify 2, and others could specify
> another cap based on resource requirements and/or a constant to
> indicate an unbounded number.

If robust activity sharing is ever going to make it past the Sugar GUI
barrier, adding sharing properties to a Sugar-specific config file
will just create an issue that needs cleaning up later.  Wouldn't it
be better to add a function or argument to the sharing API, that an
application can use to limit the number of participants sharing the

The world and the kids would be better off with e.g. a GNU Chess/
XBoard that's able to share on any platform, rather than a "Chess
Activity" that only shares under Sugar.


Devel mailing list

Reply via email to