stop sharing an activity [Devel Digest, Vol 63, Issue 56]
Yioryos Asprobounitis
mavrothal at yahoo.com
Mon May 30 10:17:45 EDT 2011
> Message: 6
> Date: Mon, 30 May 2011 12:59:08 +0200
> From: Simon Schampijer <simon at schampijer.de>
> Subject: Re: stop sharing an activity
> To: devel at lists.laptop.org
> Message-ID: <4DE3787C.50106 at schampijer.de>
> Content-Type: text/plain; charset=ISO-8859-1;
> format=flowed
>
> On 05/30/2011 07:36 AM, Yioryos Asprobounitis wrote:
> >
> > --- On Sun, 5/29/11, James Cameron<quozl at laptop.org>
> wrote:
> >
> >> I don't know where that discussion might be, but
> the
> >> concept follows the
> >> maxim that once information is released there's no
> going
> >> back.
> >>
> >
> > Thanks for the detailed info.
> > For sure once information is released there is no
> going back,
> > but I do not think activity sharing/collaboration is
> anything close to that as a concept or practice.
> > Today other collaboration tools allow not only
> collaboration to stop but also who and how to collaborate.
> > I can see many scenarios in and out of a class that
> may need that feature and I'm actually surprised is not(?)
> brought up by any deployment yet.
>
> Actually, I happened to think about it yesterday.
>
> Of course the 'unshare' functionality this adds a bit more
> complexity to
> the issue, which I think is the main reason why it is not
> handled as of
> today. At the moment, what you do when you want to stop a
> shared session
> is that you close the activity.
"Quit to stop sharing" could be sufficient I think if the sharing status of the activity was not saved in the journal.
Instead of automatically re-opening as shared could require users to explicitly activate sharing again if need/want to.
This may be simpler than a proper "stop sharing"(?)
On the other hand, would be very useful to know that the specific instance of the activity was shared.
Maybe just keep a "shared flag" instead of the sharing status in the journal and prompt the user to share it again on re-open (if simpler/HUI acceptable)?
I guess a ticket is the way to go.
>
> So activities at the moment have to be aware of that fact
> and should be
> able to handle those cases cleanly (person who joined/the
> person who
> started the shared session are leaving). However, for
> 'unshare' you have
> to handle as well this case, the activity state change, in
> your activity
> and this might be a bit trickier, or at least adds more
> complex code.
>
> Regards,
> Simon
>
>
More information about the Devel
mailing list