Re: [Sugar-devel] Thoughts on Collab

[Tony Anderson]

Hi, Sam

The neighborhood view shows laptops that are connected by the network. I 
have no idea how you expect to have a concurrent connection with the 
school server and an ad hoc network (let alone those who are connected 
to different ad hoc networks). If you were successful, then all laptops 
would see messages on all four networks - which probably would increase 
latency.


Tony

On 07/25/2016 12:39 PM, Sam Parkinson wrote:
The current system is confusing.  It limits your discovery of peers - 
the neighbourhood view ether shows buddies from the school server OR 
buddies from avahi (local network)


In the new system, we will avoid this limitation.  You will be able to 
see buddies on the schoolserver and avhai at the same time.  It will 
not make a difference from a user perspective.


If this makes the local network collaboration more widely used, I'm 
excited about that.  Obviously, direct local communication has less 
latency than using a server.  Less latency is a better user experience!


Thanks,
Sam
On Mon, Jul 25, 2016 at 4:38 PM, Tony Anderson  
wrote:
Hi, Sam I am still having a problem. You were referring to XMPP not 
avahi. Tony On 07/25/2016 01:03 AM, Sam Parkinson wrote:


On Sun, Jul 24, 2016 at 9:35 PM, Tony Anderson
> wrote:

I'm sorry. I don't understand you. Currently collaboration in
locations with a school server is done by ejabberd. This
resulted from the fact that the original mesh and later ad
hoc networks did not support the requirements of actual
deployments. This means the software supports XMMP to connect
with jabber servers. 


Avahi is *not* the mesh or adhoc network. Avahi broadcasts things
over a local wifi network - one with routers and stuff. It
doesn't do mesh or adhoc. 



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [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...@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-requ...@lists.sugarlabs.org> wrote:
>
>> Send Sugar-devel mailing list submissions to
>> sugar-devel@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-requ...@lists.sugarlabs.org
>>
>> You can reach the person managing the list at
>> sugar-devel-ow...@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 <d...@lab6.com>
>> To: Sebastian Silva <sebast...@fuentelibre.org>
>> Cc: sugar-devel <sugar-devel@lists.sugarlabs.org>, "Sam P."
>> <sam.parkins...@gmail.com>
>> Subject: Re: [Sugar-devel] Thoughts on Collab
>> Message-ID:
>> <CAEozd0zY5ve1YOnOdsV7fhkpWcyrD+h3mkL-xDE=YMUex8cT=
>> w...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> On Jul 26, 2016 4:12 PM, "Sebastian Silva" <sebast...@fuentelibre.org>
>> wrote:
>> >
>> > El 26/07/16 a las 14:05, Dave Crossland escribió:
>> >>
>> >>
>> >> On Jul 26, 2016 2:36 PM, "Sebastian Silva" <sebast...@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 a

Re: [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-requ...@lists.sugarlabs.org> wrote:

> Send Sugar-devel mailing list submissions to
> sugar-devel@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-requ...@lists.sugarlabs.org
>
> You can reach the person managing the list at
> sugar-devel-ow...@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 <d...@lab6.com>
> To: Sebastian Silva <sebast...@fuentelibre.org>
> Cc: sugar-devel <sugar-devel@lists.sugarlabs.org>, "Sam P."
> <sam.parkins...@gmail.com>
> Subject: Re: [Sugar-devel] Thoughts on Collab
> Message-ID:
> <CAEozd0zY5ve1YOnOdsV7fhkpWcyrD+h3mkL-xDE=YMUex8cT=
> w...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Jul 26, 2016 4:12 PM, "Sebastian Silva" <sebast...@fuentelibre.org>
> wrote:
> >
> > El 26/07/16 a las 14:05, Dave Crossland escribió:
> >>
> >>
> >> On Jul 26, 2016 2:36 PM, "Sebastian Silva" <sebast...@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 c

Re: [Sugar-devel] Thoughts on Collab

[Sebastian Silva]

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"...

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Dave Crossland]

On Jul 26, 2016 4:12 PM, "Sebastian Silva" 
wrote:
>
> El 26/07/16 a las 14:05, Dave Crossland escribió:
>>
>>
>> On Jul 26, 2016 2:36 PM, "Sebastian Silva" 
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: )
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sebastian Silva]

El 26/07/16 a las 14:05, Dave Crossland escribió:

>
> On Jul 26, 2016 2:36 PM, "Sebastian Silva"  > 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.
>
> >> 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.

It is part of our philosophy to promote collaboration - at all levels -
open organizations, user freedom, git, wiki, etc.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Dave Crossland]

On Jul 26, 2016 2:36 PM, "Sebastian Silva" 
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.

And therefore the system that meets that requirement is the one used by
sugarizer today.

>> 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 :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sebastian Silva]

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.

> 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.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Dave Crossland]

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.

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.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sam Parkinson]

On Tue, Jul 26, 2016 at 8:24 PM, Tony Anderson  
wrote:
As always - the devil is in the details. Does this support 
jabber.sugarlabs.org? Does it support ejabberd.


No.  We will probably host a new server if needed.  That will be 
discussed as the implementation is done.


Does it support communication between XOs with different builds (e.g. 
0.110 with 0.94)?


No.  We are experimenting with writing a new system.  Backwards 
compatibility is *not* the aim - the aim is to remove the technical 
debut and make a system that is better for users.


It will also probably *not* be part of 0.110.  We haven't even written 
a working prototype yet.



Does it support ad hoc (the current mesh technique).


Ad hoc just creates wifi networks right?  This is targeting 
collaboration over lan wifi networks.  Again - the code has not been 
written yet.


Also, didn't you say that ad hoc is too unreliable for the real world?

Thanks,
Sam
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Tony Anderson]

As always - the devil is in the details. Does this support 
jabber.sugarlabs.org? Does it support ejabberd. Does it support 
communication between XOs with different builds (e.g. 0.110 with 0.94)? 
Does it support ad hoc (the current mesh technique).


Tony

On 07/26/2016 05:22 AM, Dave Crossland wrote:



On Jul 25, 2016 11:07 PM, "Sam Parkinson" > wrote:

>
> On Tue, Jul 26, 2016 at 12:23 PM, Dave Crossland > wrote:

>>
>> Please checkout zeromq :)
>
> Oh, that looks awesome!  I think that is much better than using tcp 
directly.

>
> Does ZeroMQ guarantee message ordering?  Eg. if I post A then B, is 
it guaranteed that everybody receives it in the order A then B?  
Message ordering seems important to some algos.


Yeah it can do this

> Is there documentation for how FontForge uses this?  I assume that 
we would want a similar implementation.


ff docs are bad :/ but the zeromq book is insanely great 



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Dave Crossland]

On Jul 25, 2016 11:07 PM, "Sam Parkinson"  wrote:
>
> On Tue, Jul 26, 2016 at 12:23 PM, Dave Crossland  wrote:
>>
>> Please checkout zeromq :)
>
> Oh, that looks awesome!  I think that is much better than using tcp
directly.
>
> Does ZeroMQ guarantee message ordering?  Eg. if I post A then B, is it
guaranteed that everybody receives it in the order A then B?  Message
ordering seems important to some algos.

Yeah it can do this

> Is there documentation for how FontForge uses this?  I assume that we
would want a similar implementation.

ff docs are bad :/ but the zeromq book is insanely great 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sam Parkinson]

On Tue, Jul 26, 2016 at 12:23 PM, Dave Crossland  wrote:

Please checkout zeromq :)

Oh, that looks awesome!  I think that is much better than using tcp 
directly.


Does ZeroMQ guarantee message ordering?  Eg. if I post A then B, is it 
guaranteed that everybody receives it in the order A then B?  Message 
ordering seems important to some algos.


Is there documentation for how FontForge uses this?  I assume that we 
would want a similar implementation.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Dave Crossland]

On Jul 25, 2016 10:13 PM, "Sam Parkinson"  wrote:
>
> On Tue, Jul 26, 2016 at 9:56 AM, Abhijit Patel 
wrote:
>>
>> I have just found python modules like socket[1]  for low level
networking interface and SocketServer[2] which simplifies the task of
writing network servers.
>>
>> Could using these modules be a better option?
>>
>> [1] https://docs.python.org/2/library/socket.html
>> [2] https://docs.python.org/2/library/socketserver.html
>> e
>> Thanks,
>> Abhijit
>
>
> Hi Abhijit,
>
> I think it would be good to just use TCP for our application protocol.
Topology wise, I think we should do like AbiWord does.  That is, we have a
"leader" and everybody connects to the leader.  The leader will then parse
the messages, optionally process them, and rebroadcast them to all the
other clients.
>
> Initially, the leader can probably be the person who 1st shared the
activity.  But if that person disconnects, or their computer looses power,
we need to change the leader.
>
> We probably can't use the socket module directly, as we need Glib
mainloop integration so we don't block the ui.  GLib will take a file
handle and give us a mainloop IOChannel via this api [1].

Please checkout zeromq :)

> [1]
http://lazka.github.io/pgi-docs/index.html#GLib-2.0/structs/IOChannel.html#GLib.IOChannel.unix_new
> [2]
https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-channel-unix-new
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sam Parkinson]

On Tue, Jul 26, 2016 at 9:56 AM, Abhijit Patel 
 wrote:
I have just found python modules like socket[1]  for low level 
networking interface and SocketServer[2] which simplifies the task of 
writing network servers.


Could using these modules be a better option?

[1] https://docs.python.org/2/library/socket.html
[2] https://docs.python.org/2/library/socketserver.html
e
Thanks,
Abhijit



Hi Abhijit,

I think it would be good to just use TCP for our application protocol.  
Topology wise, I think we should do like AbiWord does.  That is, we 
have a "leader" and everybody connects to the leader.  The leader will 
then parse the messages, optionally process them, and rebroadcast them 
to all the other clients.


Initially, the leader can probably be the person who 1st shared the 
activity.  But if that person disconnects, or their computer looses 
power, we need to change the leader.


We probably can't use the socket module directly, as we need Glib 
mainloop integration so we don't block the ui.  GLib will take a file 
handle and give us a mainloop IOChannel via this api [1].


[1] 
http://lazka.github.io/pgi-docs/index.html#GLib-2.0/structs/IOChannel.html#GLib.IOChannel.unix_new
[2] 
https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-channel-unix-new
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Abhijit Patel]

On 25 July 2016 at 21:30, <sugar-devel-requ...@lists.sugarlabs.org> wrote:

> Send Sugar-devel mailing list submissions to
> sugar-devel@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-requ...@lists.sugarlabs.org
>
> You can reach the person managing the list at
> sugar-devel-ow...@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 (Tony Anderson)
>2. Re: Thoughts on Collab (Sam Parkinson)
>
>
> --
>
> Message: 1
> Date: Mon, 25 Jul 2016 08:38:21 +0200
> From: Tony Anderson <tony_ander...@usa.net>
> To: Sam Parkinson <sam.parkins...@gmail.com>
> Cc: sugar-devel@lists.sugarlabs.org
> Subject: Re: [Sugar-devel] Thoughts on Collab
> Message-ID: <5795b3dd.4080...@usa.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi, Sam
>
> I am still having a problem. You were referring to XMPP not avahi.
>
> Tony
>
> On 07/25/2016 01:03 AM, Sam Parkinson wrote:
> > On Sun, Jul 24, 2016 at 9:35 PM, Tony Anderson <tony_ander...@usa.net>
> > wrote:
> >> I'm sorry. I don't understand you. Currently collaboration in
> >> locations with a school server is done by ejabberd. This resulted
> >> from the fact that the original mesh and later ad hoc networks did
> >> not support the requirements of actual deployments. This means the
> >> software supports XMMP to connect with jabber servers.
> >
> > Avahi is *not* the mesh or adhoc network.
> >
> > Avahi broadcasts things over a local wifi network - one with routers
> > and stuff.  It doesn't do mesh or adhoc.
>
>
>
> ------
>
> Message: 2
> Date: Mon, 25 Jul 2016 20:39:49 +1000
> From: Sam Parkinson <sam.parkins...@gmail.com>
> To: Tony Anderson <tony_ander...@usa.net>
> Cc: sugar-devel@lists.sugarlabs.org
> Subject: Re: [Sugar-devel] Thoughts on Collab
> Message-ID: <1469443189.395...@smtp.gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> The current system is confusing.  It limits your discovery of peers -
> the neighbourhood view ether shows buddies from the school server OR
> buddies from avahi (local network)
>
> In the new system, we will avoid this limitation.  You will be able to
> see buddies on the schoolserver and avhai at the same time.  It will
> not make a difference from a user perspective.
>
> If this makes the local network collaboration more widely used, I'm
> excited about that.  Obviously, direct local communication has less
> latency than using a server.  Less latency is a better user experience!
>

I have just found python modules like socket[1]  for low level networking
interface and SocketServer[2] which simplifies the task of writing network
servers.

Could using these modules be a better option?

[1] https://docs.python.org/2/library/socket.html
[2] https://docs.python.org/2/library/socketserver.html

Thanks,
Abhijit

>
> Thanks,
> Sam
> On Mon, Jul 25, 2016 at 4:38 PM, Tony Anderson <tony_ander...@usa.net>
> wrote:
> > Hi, Sam
> >
> > I am still having a problem. You were referring to XMPP not avahi.
> >
> > Tony
> >
> > On 07/25/2016 01:03 AM, Sam Parkinson wrote:
> >> On Sun, Jul 24, 2016 at 9:35 PM, Tony Anderson
> >> <tony_ander...@usa.net> wrote:
> >>> I'm sorry. I don't understand you. Currently collaboration in
> >>> locations with a school server is done by ejabberd. This resulted
> >>> from the fact that the original mesh and later ad hoc networks did
> >>> not support the requirements of actual deployments. This means the
> >>> software supports XMMP to connect with jabber servers.
> >>
> >> Avahi is *not* the mesh or adhoc network.
> >>
> >> Avahi broadcasts things over a local wifi network - one with routers
> >> and stuff.  It doesn't do mesh or adhoc.
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160725/e2f5a4e1/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> --
>
> End of Sugar-devel Digest, Vol 93, Issue 55
> ***
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sam Parkinson]

The current system is confusing.  It limits your discovery of peers - 
the neighbourhood view ether shows buddies from the school server OR 
buddies from avahi (local network)


In the new system, we will avoid this limitation.  You will be able to 
see buddies on the schoolserver and avhai at the same time.  It will 
not make a difference from a user perspective.


If this makes the local network collaboration more widely used, I'm 
excited about that.  Obviously, direct local communication has less 
latency than using a server.  Less latency is a better user experience!


Thanks,
Sam
On Mon, Jul 25, 2016 at 4:38 PM, Tony Anderson  
wrote:

Hi, Sam

I am still having a problem. You were referring to XMPP not avahi.

Tony

On 07/25/2016 01:03 AM, Sam Parkinson wrote:
On Sun, Jul 24, 2016 at 9:35 PM, Tony Anderson 
 wrote:
I'm sorry. I don't understand you. Currently collaboration in 
locations with a school server is done by ejabberd. This resulted 
from the fact that the original mesh and later ad hoc networks did 
not support the requirements of actual deployments. This means the 
software supports XMMP to connect with jabber servers.


Avahi is *not* the mesh or adhoc network.

Avahi broadcasts things over a local wifi network - one with routers 
and stuff.  It doesn't do mesh or adhoc.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Tony Anderson]

Hi, Sam

I am still having a problem. You were referring to XMPP not avahi.

Tony

On 07/25/2016 01:03 AM, Sam Parkinson wrote:
On Sun, Jul 24, 2016 at 9:35 PM, Tony Anderson  
wrote:
I'm sorry. I don't understand you. Currently collaboration in 
locations with a school server is done by ejabberd. This resulted 
from the fact that the original mesh and later ad hoc networks did 
not support the requirements of actual deployments. This means the 
software supports XMMP to connect with jabber servers.


Avahi is *not* the mesh or adhoc network.

Avahi broadcasts things over a local wifi network - one with routers 
and stuff.  It doesn't do mesh or adhoc.


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sam Parkinson]

On Sun, Jul 24, 2016 at 9:35 PM, Tony Anderson  
wrote:
I'm sorry. I don't understand you. Currently collaboration in 
locations with a school server is done by ejabberd. This resulted 
from the fact that the original mesh and later ad hoc networks did 
not support the requirements of actual deployments. This means the 
software supports XMMP to connect with jabber servers.


Avahi is *not* the mesh or adhoc network.

Avahi broadcasts things over a local wifi network - one with routers 
and stuff.  It doesn't do mesh or adhoc.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Lionel Laské]

Hi Sam,

Thanks for your feedback.

You're right for the serverless collaboration, it's something I would like
to integrate too in Sugarizer.
Unfortunately the web nature of Sugarizer force me to don't rely on client
side technology out of the browser.
And currently, there is no technology (neither websockets, neither webRTC,
...) that allow peer-to-peer communication between browsers.
Hopefully one day. Some guys at Mozilla proposed some beta implementation.

Regarding your idea to resume private activity from the server, I've solved
the issue differently.
The Journal view show three different views (see at the bottom of the
Journal page): the local one (content store in the browser), the private
cloud (content store on the server but viewable only by the user), the
shared cloud (content store on the server but viewable by any user
connected to the server). You could test it yourself or see a short video
of this features here [1].

Best regards.

Lionel.

[1]
http://www.dailymotion.com/video/x1zypes_sugarizer-server-features_school



2016-07-24 12:15 GMT+02:00 Sam Parkinson <sam.parkins...@gmail.com>:

> Hi Lionel,
>
> I like the experience that you have made with Sugarizer collab.  It is
> very smooth!
>
> I think that Sugar would probably do a few things differently though.  I
> want to support serverless collaboration.  I have a few reasons for this:
>
> *  Some friends go to the library after school to work on their
> assignment.  They both connect to the library wifi.  Because they are on
> the same wifi, they see each other highlighted in the neighbourhood view.
> They collaborate over LAN, giving them a significantly more snappy
> experience.
> *  The reduced latency also suppresses most of the edge cases in the
> application that would have resulted in the documents getting out of sync.
> *  A group of teachers from a collection of schools (sometimes called a
> "network") meet up for PL/PD.  Collab just works, even though they are from
> different schools (which have different servers)
>
> Do they seem reasonable?
>
> Going a bit more in the weeds, I would probably make 1 change to the
> neighboured model, compared to you great implementation!  My plan is that
> every activity, public and private is boradcast on the server.  All
> broadcast activities share their "activity_id", but only the public
> activities also share their title, type and description.  This would let us
> make the "resume shared activity" feature work; resuming an activity now
> becomes checking if the activity is broadcast then either joining the
> broadcast activity or just resuming it normally.  I think this is the type
> of experience users expect after things like google docs.
>
> Thanks,
> Sam
>
>
> On Sun, Jul 24, 2016 at 6:09 PM, Lionel Laské <lionel.la...@gmail.com>
> wrote:
>
>
> Hi Sam,
>
> I suggest you to have a look on Sugarizer Server.
> Features 1) and 2) are already implemented and could be used into several
> Sugarizer activities (Chat, Paint, Memory, ...). Plus the Sugarizer Server
> is already include in XSCE, thanks to Tim.
> You could test the implementation here [1] (use 2 browsers to test it) and
> see more information on Server implementation here [2]. Finally most of the
> code, based on Web Socket, is here [3][4].
>
> Best regards from France.
>
>   Lionel.
>
> [1] http://server.sugarizer.org
> [2] https://github.com/llaske/Sugarizer#server
> [3] https://github.com/llaske/sugarizer/blob/master/server/presence.js
> [4]
> https://github.com/llaske/sugarizer/blob/master/lib/sugar-web/presence.js
>
> 2016-07-24 2:36 GMT+02:00 <sugar-devel-requ...@lists.sugarlabs.org>:
>
>> Date: Sun, 24 Jul 2016 10:36:00 +1000
>> From: sam@sam.today
>> To: Sugar-dev Devel <sugar-devel@lists.sugarlabs.org>, Abhijit Patel
>> <abhisandhyasp...@gmail.com>
>> Subject: [Sugar-devel] Thoughts on Collab
>> Message-ID: <1469320560.190...@smtp.gmail.com>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Hi All,
>>
>> In the irc meeting 2 nights ago, we discussed adding collaberation to
>> the journal project feature.  Abhijit has spent around 3 weeks working
>> on it.  But we can't even get a text channel between the participants.
>> Telepathy is painful, buggy (we have a segfault in salut) and hard to
>> debug.  It is also unmaintained - the last commit to telepathy salut
>> and gabble was 2 years ago.
>>
>> So this is the pre-text for an experiment; modernising the
>> collaboration stack without using telepathy.
>>
>> Initially, I proposed Matrix.Org.  I don't support this idea any more,
>>

Re: [Sugar-devel] Thoughts on Collab

[Tony Anderson]

I'm sorry. I don't understand you. Currently collaboration in locations 
with a school server is done by ejabberd. This resulted from the fact 
that the original mesh and later ad hoc networks did not support the 
requirements of actual deployments. This means the software supports 
XMMP to connect with jabber servers.


Tony

On 07/24/2016 12:03 PM, Sam Parkinson wrote:
I actually don't want to use XMPP for the new collab system.  I don't 
care how nice the library is.  Telepathy isn't the best, maybe pyxmpp2 
or nbxmpp are better.  But xmpp is not the right protocol for sugar.


Say you want to solve problem 2 and have a shared group channel.  You 
could use xmpp, but then every message you send has a huge xml wrapper 
around it adding metadata.  The metedata is useful for an IM 
application, but not very useful at all for Sugar.  So then maybe you 
use a stream tube over xmpp?  Well (at least for telepathy - but it is 
probably due to the xmpp protocol), you need to estabilish a group 
chat before you can call the stream.  Boom, added 200loc and another 
few round trips before the activity starts collaborating.


You also say that XMPP is standard, which is nice.  I like standards 
too.  But the way sugar uses xmpp, there is little point to it being 
standard.  "Standard" in Sugar content means you choose between 
ejabberd, jabberd and parsody.  You can't collaborate between Write 
activity and $other_word_processor.  You can't collaborate between 
Bibliography activity and $other_bibliography_manager.  Even if you 
could, that would be based on the "Bibliography Manager Collaboration 
Standard" - not XMPP.


Sugar has generic applications - not chat clients.   We need a generic 
application protocol - not an IM protocol.


Sebastian raised the point of backwards compatibility for his use 
case.  I think that we can provide a chat bridge no matter the 
technology.  We could also just expose chat activity inside 
traditional dekstop environments, as your work continues to move towards.


Thanks,
Sam

On Sun, Jul 24, 2016 at 6:07 PM, Tony Anderson  
wrote:
XMPP is a standard protocol (originally called jabber). Currently, 
collaboration is supported on the schoolserver by ejabberd. This 
implementation has not been changed for years AFIK. In any case, 
implementation of collaboration probably should be XMPP compliant to 
maintain maximum compatibility with what we are doing now. Tony On 
07/24/2016 08:04 AM, Sebastian Silva wrote: > Currently I can use 
gajim to chat to Sugar users (it will trigger a Chat > activity 
invitation). > > This is the level I meant when I said "backward 
compatible". > > I don't know if python-nbxmpp or python-farstream 
support some sort of > tube, but for sure the api won't be the same 
as telepathy. Those are > gajim's foundations. > > > El 24/07/16 a 
las 00:59, sam@sam.today  escribió: >> How? Who 
understands how the current code works? Can we pass xmpp >> channels 
from gijam's xmpp library to telepathy? > 
___ > Sugar-devel mailing 
list > Sugar-devel@lists.sugarlabs.org 
 > 
http://lists.sugarlabs.org/listinfo/sugar-devel 
___ Sugar-devel mailing 
list Sugar-devel@lists.sugarlabs.org 
 
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sam Parkinson]

Hi Lionel,

I like the experience that you have made with Sugarizer collab.  It is 
very smooth!


I think that Sugar would probably do a few things differently though.  
I want to support serverless collaboration.  I have a few reasons for 
this:


*  Some friends go to the library after school to work on their 
assignment.  They both connect to the library wifi.  Because they are 
on the same wifi, they see each other highlighted in the neighbourhood 
view.  They collaborate over LAN, giving them a significantly more 
snappy experience.
*  The reduced latency also suppresses most of the edge cases in the 
application that would have resulted in the documents getting out of 
sync.
*  A group of teachers from a collection of schools (sometimes called a 
"network") meet up for PL/PD.  Collab just works, even though they are 
from different schools (which have different servers)


Do they seem reasonable?

Going a bit more in the weeds, I would probably make 1 change to the 
neighboured model, compared to you great implementation!  My plan is 
that every activity, public and private is boradcast on the server.  
All broadcast activities share their "activity_id", but only the public 
activities also share their title, type and description.  This would 
let us make the "resume shared activity" feature work; resuming an 
activity now becomes checking if the activity is broadcast then either 
joining the broadcast activity or just resuming it normally.  I think 
this is the type of experience users expect after things like google 
docs.


Thanks,
Sam

On Sun, Jul 24, 2016 at 6:09 PM, Lionel Laské <lionel.la...@gmail.com> 
wrote:


Hi Sam,

I suggest you to have a look on Sugarizer Server.
Features 1) and 2) are already implemented and could be used into 
several Sugarizer activities (Chat, Paint, Memory, ...). Plus the 
Sugarizer Server is already include in XSCE, thanks to Tim.
You could test the implementation here [1] (use 2 browsers to test 
it) and see more information on Server implementation here [2]. 
Finally most of the code, based on Web Socket, is here [3][4].


Best regards from France.

  Lionel.

[1] http://server.sugarizer.org
[2] https://github.com/llaske/Sugarizer#server
[3] https://github.com/llaske/sugarizer/blob/master/server/presence.js
[4] 
https://github.com/llaske/sugarizer/blob/master/lib/sugar-web/presence.js


2016-07-24 2:36 GMT+02:00 <sugar-devel-requ...@lists.sugarlabs.org>:

Date: Sun, 24 Jul 2016 10:36:00 +1000
From: sam@sam.today
To: Sugar-dev Devel <sugar-devel@lists.sugarlabs.org>, Abhijit Patel
    <abhisandhyasp...@gmail.com>
Subject: [Sugar-devel] Thoughts on Collab
Message-ID: <1469320560.190...@smtp.gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi All,

In the irc meeting 2 nights ago, we discussed adding collaberation to
the journal project feature.  Abhijit has spent around 3 weeks 
working
on it.  But we can't even get a text channel between the 
participants.

Telepathy is painful, buggy (we have a segfault in salut) and hard to
debug.  It is also unmaintained - the last commit to telepathy salut
and gabble was 2 years ago.

So this is the pre-text for an experiment; modernising the
collaboration stack without using telepathy.

Initially, I proposed Matrix.Org.  I don't support this idea any 
more,
as matrix.org has some very messaging specific features, and some 
spots

where sugar would not fit idiomatically within the api.

So I have been thinking a little more about splitting up the problem
into 3 sections:

1)  A neighbourhood view implementation - a model to discover people
nearby or via the school server
2)  A group messaging socket - the backbone for collaboration in
activities
3)  A one-to-one file transfer mechanism - used for initial state 
sync

in activities, "send to" feature in journal, etc

I have think that we can do the neighbourhood view by using 2 
backends

and merging the result.  We can use the Avahi api to publish/find
activities/buddies on the local network.  We could additionally use a
school server (running a custom sugar server app) to support buddies
who are not on the same network.  Since both activities and buddies
have unique identifiers, we can easily have both back-ends running at
the same time, and de-duplicate the result.

Avahi is very fun to work with:

avahi-publish-service "Sam P" "_org_sugarlabs_collab_user._tcp"
8080 "name=Sam P" "color=#fff,#000" "other_metadata=other_value"
avahi-discover

All of the backends could give us an ip and a port to reach the other
person.  For the avahi backend, this would be a direct connection to
the other buddy.  For the schoolserver, it would be proxied through 
the

schoolserver.

I'd love to hear your thoughts on the other problems, and on this
problem to.

Thanks,
Sam
-- next part -

Re: [Sugar-devel] Thoughts on Collab

[Sam Parkinson]

I actually don't want to use XMPP for the new collab system.  I don't 
care how nice the library is.  Telepathy isn't the best, maybe pyxmpp2 
or nbxmpp are better.  But xmpp is not the right protocol for sugar.


Say you want to solve problem 2 and have a shared group channel.  You 
could use xmpp, but then every message you send has a huge xml wrapper 
around it adding metadata.  The metedata is useful for an IM 
application, but not very useful at all for Sugar.  So then maybe you 
use a stream tube over xmpp?  Well (at least for telepathy - but it is 
probably due to the xmpp protocol), you need to estabilish a group chat 
before you can call the stream.  Boom, added 200loc and another few 
round trips before the activity starts collaborating.


You also say that XMPP is standard, which is nice.  I like standards 
too.  But the way sugar uses xmpp, there is little point to it being 
standard.  "Standard" in Sugar content means you choose between 
ejabberd, jabberd and parsody.  You can't collaborate between Write 
activity and $other_word_processor.  You can't collaborate between 
Bibliography activity and $other_bibliography_manager.  Even if you 
could, that would be based on the "Bibliography Manager Collaboration 
Standard" - not XMPP.


Sugar has generic applications - not chat clients.   We need a generic 
application protocol - not an IM protocol.


Sebastian raised the point of backwards compatibility for his use case. 
I think that we can provide a chat bridge no matter the technology.  
We could also just expose chat activity inside traditional dekstop 
environments, as your work continues to move towards.


Thanks,
Sam

On Sun, Jul 24, 2016 at 6:07 PM, Tony Anderson  
wrote:

XMPP is a standard protocol (originally called jabber). Currently,
collaboration is supported on the schoolserver by ejabberd. This
implementation has not been changed for years AFIK.

In any case, implementation of collaboration probably should be XMPP
compliant to maintain maximum compatibility with what we are doing 
now.


Tony

On 07/24/2016 08:04 AM, Sebastian Silva wrote:
> Currently I can use gajim to chat to Sugar users (it will trigger a 
Chat

> activity invitation).
>
> This is the level I meant when I said "backward compatible".
>
> I don't know if python-nbxmpp or python-farstream support some sort 
of

> tube, but for sure the api won't be the same as telepathy. Those are
> gajim's foundations.
>
>
> El 24/07/16 a las 00:59, sam@sam.today escribió:
>> How?  Who understands how the current code works?  Can we pass xmpp
>> channels from gijam's xmpp library to telepathy?
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Tony Anderson]

The 'patch' was essentially  to place every ejabberd client in the same 
group. AFIK, there is no
strong reason not to upgrade ejabberd on the server side to a current 
release. I don't have the information
at hand but we were working with a group with focus on collaboration who 
implemented the patch - perhaps someone

remembers the group and how we could interact with them again.

There are client-side software implementations available for XMPP: 
https://github.com/Jajcus/pyxmpp2 as an example. My guess is the 
collab-wrap could support XMPP without a lot of other dependencies.


Tony

On 07/24/2016 10:09 AM, Jerry Vonau wrote:



On July 23, 2016 at 5:36 PM sam@sam.today wrote:


Hi All,

In the irc meeting 2 nights ago, we discussed adding collaberation to
the journal project feature.  Abhijit has spent around 3 weeks working
on it.  But we can't even get a text channel between the participants.
Telepathy is painful, buggy (we have a segfault in salut) and hard to
debug.  It is also unmaintained - the last commit to telepathy salut
and gabble was 2 years ago.

So this is the pre-text for an experiment; modernising the
collaboration stack without using telepathy.

Initially, I proposed Matrix.Org.  I don't support this idea any more,
as matrix.org has some very messaging specific features, and some spots
where sugar would not fit idiomatically within the api.

So I have been thinking a little more about splitting up the problem
into 3 sections:

1)  A neighbourhood view implementation - a model to discover people
nearby or via the school server
2)  A group messaging socket - the backbone for collaboration in
activities
3)  A one-to-one file transfer mechanism - used for initial state sync
in activities, "send to" feature in journal, etc

I have think that we can do the neighbourhood view by using 2 backends
and merging the result.  We can use the Avahi api to publish/find
activities/buddies on the local network.  We could additionally use a
school server (running a custom sugar server app) to support buddies
who are not on the same network.  Since both activities and buddies
have unique identifiers, we can easily have both back-ends running at
the same time, and de-duplicate the result.

Avahi is very fun to work with:

 avahi-publish-service "Sam P" "_org_sugarlabs_collab_user._tcp"
8080 "name=Sam P" "color=#fff,#000" "other_metadata=other_value"
 avahi-discover

All of the backends could give us an ip and a port to reach the other
person.  For the avahi backend, this would be a direct connection to
the other buddy.  For the schoolserver, it would be proxied through the
schoolserver.


FWIW, I plan on dropping support for gabble within XSCE as the code base is
very old and I'm not fond of maintaining the fork, with OLPC's patch, of
ejabberd. The only reason I have not done so yet is that the package still
installs but nobody is testing the functionality. Should the server side
get updated and straitened out I would welcome keeping ejabberd in the XSCE
fold. Just don't look to have the XSCE project help with the development of
the updating, but testing of the updated server side we might help with as
I can't speak for everybody involved. Pull requests welcome.

Jerry



I'd love to hear your thoughts on the other problems, and on this
problem to.

Thanks,
Sam
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Lionel Laské]

Hi Sam,

I suggest you to have a look on Sugarizer Server.
Features 1) and 2) are already implemented and could be used into several
Sugarizer activities (Chat, Paint, Memory, ...). Plus the Sugarizer Server
is already include in XSCE, thanks to Tim.
You could test the implementation here [1] (use 2 browsers to test it) and
see more information on Server implementation here [2]. Finally most of the
code, based on Web Socket, is here [3][4].

Best regards from France.

  Lionel.

[1] http://server.sugarizer.org
[2] https://github.com/llaske/Sugarizer#server
[3] https://github.com/llaske/sugarizer/blob/master/server/presence.js
[4]
https://github.com/llaske/sugarizer/blob/master/lib/sugar-web/presence.js

2016-07-24 2:36 GMT+02:00 <sugar-devel-requ...@lists.sugarlabs.org>:

> Date: Sun, 24 Jul 2016 10:36:00 +1000
> From: sam@sam.today
> To: Sugar-dev Devel <sugar-devel@lists.sugarlabs.org>, Abhijit Patel
> <abhisandhyasp...@gmail.com>
> Subject: [Sugar-devel] Thoughts on Collab
> Message-ID: <1469320560.190...@smtp.gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi All,
>
> In the irc meeting 2 nights ago, we discussed adding collaberation to
> the journal project feature.  Abhijit has spent around 3 weeks working
> on it.  But we can't even get a text channel between the participants.
> Telepathy is painful, buggy (we have a segfault in salut) and hard to
> debug.  It is also unmaintained - the last commit to telepathy salut
> and gabble was 2 years ago.
>
> So this is the pre-text for an experiment; modernising the
> collaboration stack without using telepathy.
>
> Initially, I proposed Matrix.Org.  I don't support this idea any more,
> as matrix.org has some very messaging specific features, and some spots
> where sugar would not fit idiomatically within the api.
>
> So I have been thinking a little more about splitting up the problem
> into 3 sections:
>
> 1)  A neighbourhood view implementation - a model to discover people
> nearby or via the school server
> 2)  A group messaging socket - the backbone for collaboration in
> activities
> 3)  A one-to-one file transfer mechanism - used for initial state sync
> in activities, "send to" feature in journal, etc
>
> I have think that we can do the neighbourhood view by using 2 backends
> and merging the result.  We can use the Avahi api to publish/find
> activities/buddies on the local network.  We could additionally use a
> school server (running a custom sugar server app) to support buddies
> who are not on the same network.  Since both activities and buddies
> have unique identifiers, we can easily have both back-ends running at
> the same time, and de-duplicate the result.
>
> Avahi is very fun to work with:
>
> avahi-publish-service "Sam P" "_org_sugarlabs_collab_user._tcp"
> 8080 "name=Sam P" "color=#fff,#000" "other_metadata=other_value"
> avahi-discover
>
> All of the backends could give us an ip and a port to reach the other
> person.  For the avahi backend, this would be a direct connection to
> the other buddy.  For the schoolserver, it would be proxied through the
> schoolserver.
>
> I'd love to hear your thoughts on the other problems, and on this
> problem to.
>
> Thanks,
> Sam
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160724/569b6610/attachment.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> --
>
> End of Sugar-devel Digest, Vol 93, Issue 50
> ***
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Jerry Vonau]

> On July 23, 2016 at 5:36 PM sam@sam.today wrote:
> 
> 
> Hi All,
> 
> In the irc meeting 2 nights ago, we discussed adding collaberation to 
> the journal project feature.  Abhijit has spent around 3 weeks working 
> on it.  But we can't even get a text channel between the participants.  
> Telepathy is painful, buggy (we have a segfault in salut) and hard to 
> debug.  It is also unmaintained - the last commit to telepathy salut 
> and gabble was 2 years ago.
> 
> So this is the pre-text for an experiment; modernising the 
> collaboration stack without using telepathy.
> 
> Initially, I proposed Matrix.Org.  I don't support this idea any more, 
> as matrix.org has some very messaging specific features, and some spots 
> where sugar would not fit idiomatically within the api.
> 
> So I have been thinking a little more about splitting up the problem 
> into 3 sections:
> 
> 1)  A neighbourhood view implementation - a model to discover people 
> nearby or via the school server
> 2)  A group messaging socket - the backbone for collaboration in 
> activities
> 3)  A one-to-one file transfer mechanism - used for initial state sync 
> in activities, "send to" feature in journal, etc
> 
> I have think that we can do the neighbourhood view by using 2 backends 
> and merging the result.  We can use the Avahi api to publish/find 
> activities/buddies on the local network.  We could additionally use a 
> school server (running a custom sugar server app) to support buddies 
> who are not on the same network.  Since both activities and buddies 
> have unique identifiers, we can easily have both back-ends running at 
> the same time, and de-duplicate the result.
> 
> Avahi is very fun to work with:
> 
> avahi-publish-service "Sam P" "_org_sugarlabs_collab_user._tcp" 
> 8080 "name=Sam P" "color=#fff,#000" "other_metadata=other_value"
> avahi-discover
> 
> All of the backends could give us an ip and a port to reach the other 
> person.  For the avahi backend, this would be a direct connection to 
> the other buddy.  For the schoolserver, it would be proxied through the 
> schoolserver.
> 

FWIW, I plan on dropping support for gabble within XSCE as the code base is
very old and I'm not fond of maintaining the fork, with OLPC's patch, of
ejabberd. The only reason I have not done so yet is that the package still
installs but nobody is testing the functionality. Should the server side
get updated and straitened out I would welcome keeping ejabberd in the XSCE
fold. Just don't look to have the XSCE project help with the development of
the updating, but testing of the updated server side we might help with as
I can't speak for everybody involved. Pull requests welcome.

Jerry  


> I'd love to hear your thoughts on the other problems, and on this 
> problem to.
> 
> Thanks,
> Sam
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Tony Anderson]

XMPP is a standard protocol (originally called jabber). Currently, 
collaboration is supported on the schoolserver by ejabberd. This 
implementation has not been changed for years AFIK.


In any case, implementation of collaboration probably should be XMPP 
compliant to maintain maximum compatibility with what we are doing now.


Tony

On 07/24/2016 08:04 AM, Sebastian Silva wrote:

Currently I can use gajim to chat to Sugar users (it will trigger a Chat
activity invitation).

This is the level I meant when I said "backward compatible".

I don't know if python-nbxmpp or python-farstream support some sort of
tube, but for sure the api won't be the same as telepathy. Those are
gajim's foundations.


El 24/07/16 a las 00:59, sam@sam.today escribió:

How?  Who understands how the current code works?  Can we pass xmpp
channels from gijam's xmpp library to telepathy?

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sebastian Silva]

Currently I can use gajim to chat to Sugar users (it will trigger a Chat
activity invitation).

This is the level I meant when I said "backward compatible".

I don't know if python-nbxmpp or python-farstream support some sort of
tube, but for sure the api won't be the same as telepathy. Those are
gajim's foundations.


El 24/07/16 a las 00:59, sam@sam.today escribió:
>
> How?  Who understands how the current code works?  Can we pass xmpp
> channels from gijam's xmpp library to telepathy?

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[sam]

On Sun, Jul 24, 2016 at 2:03 PM, Sebastian Silva 
 wrote:

El 23/07/16 a las 19:36, sam@sam.today escribió:

Avahi is very fun to work with:

avahi-publish-service "Sam P" "_org_sugarlabs_collab_user._tcp" 
8080 "name=Sam P" "color=#fff,#000" "other_metadata=other_value"

avahi-discover

All of the backends could give us an ip and a port to reach the 
other person.  For the avahi backend, this would be a direct 
connection to the other buddy.  For the schoolserver, it would be 
proxied through the schoolserver.


I'd love to hear your thoughts on the other problems, and on this 
problem to.


It sounds like you have your mind set on a solution already, from the 
ground up. That's fine if you are willing to tackle the task.


I'm more of a re-user.


+1 for re-using.  However, we need to ensure that when we re-use, we 
re-use something that is good quality and that is a good fit for sugar. 
Telepathy has become a little bit of a bad fit for sugar.


My attitude now is to a) not use telepathy, and b) not make the same 
mistake again.





I always thought XMPP was a good idea. Have you tried gajim?

https://gajim.org/

It is an XMPP client that is allso P2P and fully written in 
Python/GTK.


I've never herd of it :)  I suppose I will look into it.




Perhaps some of its code can be reused, for F1 view and other goals. 
I think a solution on top of this could even be made backward 
compatible with current Sugar (for the most part).


How?  Who understands how the current code works?  Can we pass xmpp 
channels from gijam's xmpp library to telepathy?


Thanks,
Sam




I'm all for a custom server component, perhaps it could be built on 
top of this.


Regards,
Sebastian

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Thoughts on Collab

[Sebastian Silva]

El 23/07/16 a las 19:36, sam@sam.today escribió:

> Avahi is very fun to work with:
>
> avahi-publish-service "Sam P" "_org_sugarlabs_collab_user._tcp"
> 8080 "name=Sam P" "color=#fff,#000" "other_metadata=other_value"
> avahi-discover
>
> All of the backends could give us an ip and a port to reach the other
> person.  For the avahi backend, this would be a direct connection to
> the other buddy.  For the schoolserver, it would be proxied through
> the schoolserver.
>
> I'd love to hear your thoughts on the other problems, and on this
> problem to.

It sounds like you have your mind set on a solution already, from the
ground up. That's fine if you are willing to tackle the task.

I'm more of a re-user.

I always thought XMPP was a good idea. Have you tried /gajim/?

https://gajim.org/

It is an XMPP client that is allso P2P and fully written in Python/GTK.

Perhaps some of its code can be reused, for F1 view and other goals. I
think a solution on top of this could even be made backward compatible
with current Sugar (for the most part).

I'm all for a custom server component, perhaps it could be built on top
of this.

Regards,
Sebastian

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Thoughts on Collab

[sam]

Hi All,

In the irc meeting 2 nights ago, we discussed adding collaberation to 
the journal project feature.  Abhijit has spent around 3 weeks working 
on it.  But we can't even get a text channel between the participants.  
Telepathy is painful, buggy (we have a segfault in salut) and hard to 
debug.  It is also unmaintained - the last commit to telepathy salut 
and gabble was 2 years ago.


So this is the pre-text for an experiment; modernising the 
collaboration stack without using telepathy.


Initially, I proposed Matrix.Org.  I don't support this idea any more, 
as matrix.org has some very messaging specific features, and some spots 
where sugar would not fit idiomatically within the api.


So I have been thinking a little more about splitting up the problem 
into 3 sections:


1)  A neighbourhood view implementation - a model to discover people 
nearby or via the school server
2)  A group messaging socket - the backbone for collaboration in 
activities
3)  A one-to-one file transfer mechanism - used for initial state sync 
in activities, "send to" feature in journal, etc


I have think that we can do the neighbourhood view by using 2 backends 
and merging the result.  We can use the Avahi api to publish/find 
activities/buddies on the local network.  We could additionally use a 
school server (running a custom sugar server app) to support buddies 
who are not on the same network.  Since both activities and buddies 
have unique identifiers, we can easily have both back-ends running at 
the same time, and de-duplicate the result.


Avahi is very fun to work with:

   avahi-publish-service "Sam P" "_org_sugarlabs_collab_user._tcp" 
8080 "name=Sam P" "color=#fff,#000" "other_metadata=other_value"

   avahi-discover

All of the backends could give us an ip and a port to reach the other 
person.  For the avahi backend, this would be a direct connection to 
the other buddy.  For the schoolserver, it would be proxied through the 
schoolserver.


I'd love to hear your thoughts on the other problems, and on this 
problem to.


Thanks,
Sam
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel