[Sugar-devel] Collaboration support for sugar web activities

[Daniel Narvaez]

On 20 January 2014 13:53, Emil Dudev <emildudev at gmail.com> wrote:

> On Mon, Jan 20, 2014 at 12:48 PM, Daniel Narvaez <dwnarvaez at gmail.com>wrote:
>
>> * Why did you go with a separate web activity instead on integrating
>> directly in the shell?
>>
> Integrating it directly with the current neighborhood?
>

Not necessarily, I was also wondering why you didn't write the same thing
in python inside the shell. But now I probably see, an activity was the
only sensible place to put it if you wasn't merging with the telepathy view.

One problem would be of duplicates if a user is both on the telepathy
> neighborhood and this 'new' one.
> As mentioned in the earlier messages, I was thinking of writing a python
> class that would act as the client between the sugar's mesh and the web
> socket server.
> I wasn't sure how exactly to handle regular activities and web activities
> in such a 'merged' neighborhood.
>

I'm not sure to understand where we would get duplicates. It seems like the
mesh view is a list of activities. The new framework will provide you
another list. Isn't it just matter of merging the two? Even in the current
view if the user is in two activities, I believe we show it two times.
(Might very well be missing something!).

The reason I want to figure out if it's possible to merge the views is that
we are not going to be able to drop telepathy based collaboration any time
soon. We will have first to prove that the new framework works better and
get activity authors to buy into it, then deprecate, finally wait a few
years for activities to be migrated. So we need a plan on how the two can
coexist. I'm afraid having two separate views it's not something we can
afford user experience wise... but it would be good to hear the design team
opinions on this.


>
>> * Would it be possible to implement this without adding to apisocket and
>> thus making it sugar specific?
>>
> Making web collaboration sugar specific, or not (being able to collaborate
> from a normal browser)?
> Since apisocket.py is the only way to communicate between the javascript
> code and sugar, I'd say it won't be easy.
> As noted above, it won't be very easy to have collaboration outside of
> sugar, because the browser does not know where the activity page lies (if
> it needs to join/open an activity).
> It is possible to join a web activity, without changes to apisocket.py.
> The problem would be that the current webkit page (sugar-net activity)
> would be overwritten by the new activity (the one that is joined). There's
> no problem from the web activity's point of view. The problem is that sugar
> would still think that this is the sugar-net activity, and I'm not sure
> what that would lead to. An other problem is that the sugar-net activity is
> lost (it's page was reloaded into the joined activity).
> A possible way to solve this is to open the new activity's page into a
> separate tab. But then there are other problems: sugar would think the
> sugar-net activity and it's new tab (the new activity) are one. Also, I'm
> not sure how tab handling would look in webkit, without the top navigation
> bars.
>

Yeah, some sugar specific bits will be necessary to launch the activity. It
seems like it would be good to keep those bits as minimal as possible.


>
> The questions don't seem to have simple answers...
> When I'm writing the code, I'm not sure which way to go. I don't believe
> that I can decide what is best for sugar. It would be nice to know what the
> community is thinking and what is their vision of how web collaboration
> should be handled.
>

Yes. I think we are all a bit unsure about the way we should go. The
research you are doing is extremely valuable because it's bringing us
closer to figure that out... Lionel and Suraj has been experimenting with
collaboration too, so it would be very interesting to hear their feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140120/fb04adf2/attachment.html>