[Sugar-devel] Thoughts on Collab

[Abhijit Patel]

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/ceb3388a/attachment.html>