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