[Sugar-devel] Thoughts on Collab

[Sam P.]

Looking great.  I will test it very soon, but the code looks nice.

We probably now need to look at activity collab.  I was thinking that we
have a leader, and everybody connects to the leader.  The connection
protocol could be zeromq or whatever you think is best.  We need to have
authentication so that only invited people can join the activity (unless it
is public) - this would be part of the "leader"s server code.  Otherwise
the server would just re-broadcast incoming messages to everybody else.
The server could just run inside the activity process.  It would be best if
the "server" could be subclasses by activities - eg. to implement text
editing algorithms.

Encryption would also be useful.  I think there is something called CurveMQ
which adds encryption to ZeroMQ, but you can investigate that.

What do you think about that?

Thanks,
Sam

On Fri, Jul 29, 2016 at 9:54 AM, Abhijit Patel <abhisandhyasp.ap at gmail.com>
wrote:

> Hi all,
> I have implemented the neighborhood view using Avahi instead of telepathy.
> Here, all the buddies that are connected to the same port are shown in
> neighborhood view.
>
> Whenever buddy gets connected he adds a service to an EntryGroup which is
> discovered by all buddies(including the ones that are connected later) and
> hence buddy is added to neighborhood.
>
> And when buddy gets disconnected the service started by that buddy is
> stopped and hence removed from the ServiceBrowser this emits a signal
> "ItemRemove" which is received by other buddies and hence buddy
> disconnected is removed from the neighborhood view.
>
> I have used profile.pub_key  to overcome the issue of duplicate buddies.
>
> You could test my code[1] and review it and even a few suggestions that
> pops up in your mind :)
> [1] https://goo.gl/PBWy08
>
> Regards,
> Abhijit
> On 27 July 2016 at 21:30, <sugar-devel-request at lists.sugarlabs.org> wrote:
>
>> Send Sugar-devel mailing list submissions to
>>         sugar-devel at lists.sugarlabs.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://lists.sugarlabs.org/listinfo/sugar-devel
>> or, via email, send a message with subject or body 'help' to
>>         sugar-devel-request at lists.sugarlabs.org
>>
>> You can reach the person managing the list at
>>         sugar-devel-owner at lists.sugarlabs.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Sugar-devel digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Thoughts on Collab (Dave Crossland)
>>    2. Re: Thoughts on Collab (Sebastian Silva)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 26 Jul 2016 19:16:30 -0400
>> From: Dave Crossland <dave at lab6.com>
>> To: Sebastian Silva <sebastian at fuentelibre.org>
>> Cc: sugar-devel <sugar-devel at lists.sugarlabs.org>, "Sam P."
>>         <sam.parkinson3 at gmail.com>
>> Subject: Re: [Sugar-devel] Thoughts on Collab
>> Message-ID:
>>         <CAEozd0zY5ve1YOnOdsV7fhkpWcyrD+h3mkL-xDE=YMUex8cT=
>> w at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> On Jul 26, 2016 4:12 PM, "Sebastian Silva" <sebastian at fuentelibre.org>
>> wrote:
>> >
>> > El 26/07/16 a las 14:05, Dave Crossland escribió:
>> >>
>> >>
>> >> On Jul 26, 2016 2:36 PM, "Sebastian Silva" <sebastian at fuentelibre.org>
>> wrote:
>> >> >
>> >> > El 26/07/16 a las 13:08, Dave Crossland escribió:
>> >> >>
>> >> >> Despite my suggestion to look at zeromq, I think we should be using
>> the collaboration protocols that Lionel is using in Sugarizer, so that
>> someone running Sugar desktop and someone using Sugarizer on a Chromebook
>> (for example, 2 kids in a family at home who attend 2 different schools
>> that have different hardware purchasing decisions ;) could collaborate.
>> >> >
>> >> > It's not a dichotomy.
>> >> >
>> >> > If two users use the same app [and it supports collaboration] - it
>> should just work regardless of the environment where they are run.
>> >> >
>> >> > Much like running etherpad @ titanpad.
>> >>
>> >> I mean to propose a requirement for any new collaboration system that
>> is
>> recommended to all sugar developers be that it support collaboration
>> between a python paint application and a Javascript paint application.
>> >
>> > That sounds challenging and not too useful.
>> >
>> >> And therefore the system that meets that requirement is the one used by
>> sugarizer today.
>>
>> Why could using the system on sugarizer from python be more challenging
>> than writing a new system with zeromq or similar? :)
>>
>> >> >> However, I am eagerly awaiting Sameer's next installment of the
>> vision quest process, because without the vision/mission/etc defined, we
>> can't make informed technical decisions about what kind of collaboration
>> protocols are best.
>> >> >
>> >> >
>> >> > Maybe we shouldn't have to judge - they can all coexist.
>> >>
>> >> An anti-design approach where no system is recommended and each
>> activity
>> developer can figure out their own system seems counter to the aims of a
>> cohesive and consistent learning platform in which collaboration is
>> promoted as a top tier feature :)
>> >
>> > User facing features are at the application level. How they are
>> implemented is only a detail. I'd rather have a paint app that
>> collaborates, no matter how it is built. Currently we have none.
>>
>> The technology that Sugar platform offers to activity developers is what
>> determines if they implement collaboration as a user facing feature. It
>> seems to me that the current platform recommendation is for something that
>> was experimental 10 years ago and has not matured in this time, so I am
>> not
>> surprised to hear central apps like paint don't implement features with
>> it.
>>
>> > It is part of our philosophy to promote collaboration - at all levels -
>> open organizations, user freedom, git, wiki, etc.
>>
>> Right - so I think its worth considering the strategic context of the
>> implementation details: )
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160726/ee8fa789/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 26 Jul 2016 19:27:29 -0500
>> From: Sebastian Silva <sebastian at fuentelibre.org>
>> To: Dave Crossland <dave at lab6.com>
>> Cc: sugar-devel <sugar-devel at lists.sugarlabs.org>, "Sam P."
>>         <sam.parkinson3 at gmail.com>
>> Subject: Re: [Sugar-devel] Thoughts on Collab
>> Message-ID: <a63ded9b-b26b-1249-6095-b1208b9bec4b at fuentelibre.org>
>> Content-Type: text/plain; charset=utf-8
>>
>>
>> El 26/07/16 a las 18:16, Dave Crossland escribió:
>>
>> > > User facing features are at the application level. How they are
>> > implemented is only a detail. I'd rather have a paint app that
>> > collaborates, no matter how it is built. Currently we have none.
>> >
>> > The technology that Sugar platform offers to activity developers is
>> > what determines if they implement collaboration as a user facing
>> > feature. It seems to me that the current platform recommendation is
>> > for something that was experimental 10 years ago and has not matured
>> > in this time, so I am not surprised to hear central apps like paint
>> > don't implement features with it.
>> >
>>
>> At the time perhaps a decision was required because the "platform"
>> needed to fit into 1GB of the XO1 nand flash.
>>
>> In this case (because we are discussing Sugar/GTK), the "platform" is
>> all of GNU/Linux.
>>
>> Perhaps the "official" recommendation should stay at the design / UI /
>> philosophical level. After all, as you say, Sugarizer uses something
>> different (that is...?).
>> >
>> > > It is part of our philosophy to promote collaboration - at all
>> > levels - open organizations, user freedom, git, wiki, etc.
>> >
>> > Right - so I think its worth considering the strategic context of the
>> > implementation details: )
>> >
>> Only if you are planning on implementing (and maintaining!) "it"...
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>> ------------------------------
>>
>> End of Sugar-devel Digest, Vol 93, Issue 60
>> *******************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160729/a4e7ffb6/attachment-0001.html>