On Mon, Feb 2, 2009 at 7:33 PM, Benjamin M. Schwartz
<bmsch...@fas.harvard.edu> wrote:
> Hash: SHA1
> Eben Eliason wrote:
>> 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.
> OK, but as an Activity author I might like to specify that cap at runtime,
> depending on many things, such as the size of the document.  I might even
> want to let the initiator choose the number of participants.  I think we
> should also have a runtime API, so that the cap that can be varied at any
> time.

That's a good observation.  You're right; I was seeing hard limits,
but soft limits could certainly be implemented via some API that Sugar
could call into to retrieve the info.  The static declaration could be
used as the fallback.

> In fact, it might be nice to have a a generic solution for defining config
> variables that can be controlled either statically or at runtime.  We have
> mentioned a wide variety of such variables, including things like whether
> screen rotation is supported.


>> Scott (CC'd) has already come up with some really nice proposals for
>> adding VNC as an alternate colaboration mechanism for all activities.
>> In my mind, this would work perfectly with the above scheme, whereby
>> any activity that already has max_participants in it could be viewed
>> in that manner.
> I don't see why any Activity should be excluded from such VNC sharing,
> regardless of max_participants.

Of course not.  I didn't mean to imply such a limitation; only that
the VNC solution would be the /only/ option after some participants
limit was reached.  That is, you could either "Join" or "Watch" any
shared activity, but the "Join" option would disappear once
"full"..."Watch" would remain. It's possible we'd have an upper bound
on the number of people who could watch as well, but I don't think
that's an activity-specific parameter.

- Eben

> - --Ben
> Version: GnuPG v2.0.9 (GNU/Linux)
> UpAAniXtXxWRQuM8o8iqtiyJ0uB4o05Z
> =BI5d
Devel mailing list

Reply via email to