Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting, 2015-05-11

 « Previous day | Index | Today | Next day »     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
01:03 satellit_e <satellit_e!~satellit@2601:8:8800:99a:468a:5bff:fe31:faeb> has joined #sugar-meeting
02:18 gonzalo_ has quit IRC
09:48 satellit_e has quit IRC
09:48 gonzalo_ <gonzalo_!~gonzalo@> has joined #sugar-meeting
09:59 satellit_e <satellit_e!~satellit@2601:8:8800:99a:468a:5bff:fe31:faeb> has joined #sugar-meeting
10:42 satellit_e has quit IRC
10:46 satellit_e <satellit_e!~satellit@2601:8:8800:99a:468a:5bff:fe31:faeb> has joined #sugar-meeting
11:07 meeting <meeting!~sugaroid@rev-18-85-44-69.sugarlabs.org> has joined #sugar-meeting
13:19 walterbender <walterbender!~walter@146-115-134-246.c3-0.nwt-ubr​1.sbo-nwt.ma.cable.rcn.com> has joined #sugar-meeting
13:19 walter_ <walter_!~walter@146-115-134-246.c3-0.nwt-ubr​1.sbo-nwt.ma.cable.rcn.com> has joined #sugar-meeting
13:46 tch__ <tch__!~tch@host-1-217.b12.cvc.com.py> has joined #sugar-meeting
14:47 rohitsakala <rohitsakala!uid32931@gateway/web/irccloud.com/x-qqbtobaviizufhps> has joined #sugar-meeting
16:28 jo0nas has quit IRC
16:29 jo0nas <jo0nas!jonas@188-183-5-254-static.dk.customer.tdc.net> has joined #sugar-meeting
17:48 tch__ has quit IRC
18:44 tch__ <tch__!~tch@> has joined #sugar-meeting
18:47 abhinav <abhinav!dce39556@gateway/web/freenode/ip.> has joined #sugar-meeting
18:51 mohayon <mohayon!~androirc@87-231-208-31.rev.numericable.fr> has joined #sugar-meeting
18:57 tch__ abhinav, ping
18:57 abhinav tch__: pong
18:58 tch__ lets wait a few minutes for lionel
18:58 abhinav, ^
18:58 abhinav Sure
19:04 llaske <llaske!~chatzilla@AVelizy-154-1-26-98.w82-124.abo.wanadoo.fr> has joined #sugar-meeting
19:05 llaske hi all, sorry I'm late
19:05 issues with my connection
19:05 mohayon Hi
19:05 abhinav Hello llaske
19:05 tch__ llaske, hey!
19:06 llaske, abhinav mohayon lets get started? ;)
19:06 abhinav Sure
19:06 llaske sure, you're the master of ceremony today
19:06 mohayon Sure
19:06 tch__ alright,
19:07 well, lets start by checking a few things :)
19:07 abhinav, mohayon have you guys tested web activities yet? sugarizer? and sugar in general?
19:07 mohayon Yes, in both platfor
19:08 *platforms
19:08 abhinav yes, i have worked with web activities during my interaction phase
19:08 and went through sugarizer nearly
19:08 llaske abhinav, did you already install Sugarizer server ?
19:08 abhinav llaske: yes
19:09 llaske did you manage the way it works, regarding MongoDB, node.js, ...
19:09 abhinav yeah
19:09 llaske nice
19:10 tch__ llaske, does the collaboration bits use some storage DB?
19:10 llaske in my mind there is two types of collaboration:
19:10 tch__ llaske, I checked the code long ago, so I can't remember
19:10 llaske - using a shared journal, so it need a storage DB
19:11 - using presence, it don't need storage: all is in the server memory
19:11 abhinav well, it should in my views ... coz we have to deal with activities like paint where we need to  store data for the last session
19:11 *paint as well
19:12 llaske that's the point, we had exactly the same discussion with mohayon last week:
19:12 let me take the example of Chat activity
19:12 the question is: do the server need to story the history of talk or not
19:12 in my mind, no
19:12 tch__ llaske, I am all ears :)
19:13 llaske so the server handle only instant data exchange
19:13 My GSoC students in 2012 wrote a functionnal overview of that here:
19:13 https://docs.google.com/docume[…]kEQEwQmX_xVX9H-s/
19:13 tch__ llaske, +1 from me, unless there is a critical need we should keep it keep, minimizing deps
19:13 s/keep/simple/
19:14 llaske yes, but in the Chat example, it means that a new user that join the Chat will not have access to history
19:14 except if others participants send it to him
19:14 abhinav true
19:14 llaske Same for Paint
19:14 abhinav thats what was bothering me
19:15 llaske moyahon tell us about your idea regarding that
19:16 tch__ llaske, the question is, does it necessary have to be in the backend? or can the "master" of the session share that information when new client join in? ie. like a stream
19:16 mohayon I thought about storing things on the server because of dev facilities
19:16 llaske who is the master of the session ?
19:16 mohayon That not simple and bring complications
19:17 llaske tch__ how it works in Sugar presence ?
19:17 abhinav mohayon: and what exactly dev facilities include?
19:17 mohayon Not having to recode store and retrieve for each app
19:18 tch__ llaske, I don't know the details, but always though it was the one who created the shared session
19:19 mohayon But for paint we talked about the data volume and it can see a great idea to store things on the server but theres to much data to handle
19:19 llaske so it mean, it let complexity in client side instead of server side
19:19 tch__ llaske, I don't think it depends on storing data in a backend, because there wasn't a backend when collaborating without jabber
19:19 mohayon has quit IRC
19:19 llaske tch__: yes of course
19:19 mohayon <mohayon!~mohayon@87-231-208-31.rev.numericable.fr> has joined #sugar-meeting
19:20 mohayon With last weeks discution, I changed my mind and having to handle things inside the app will allow to do more things
19:20 llaske So, for example in Paint, does it mean that the new user will have to receive from the master the whole events or only a bitmap of the current draw
19:21 abhinav Well, storing the data for active sessions and destroying on session end will do in this case.
19:21 tch__ llaske, is hard to "see" the trade off between using the server as a proxy for data transfer and using it a repository for data... to me it sounds like storing data could be more complex that it seems, vs having to transfer more data each time a client joins
19:22 llaske tch: +1
19:23 tch__ llaske, we could start with the "use it as a proxy" approach and then consider if some server side caching could help? but lets start with something simpler focusing on the collab protocol
19:23 abhinav tch__: +1
19:24 walter_ +1
19:24 llaske sounds good, it's why first activities developed by mohayon will give us good idea of complexity to do that from the client side
19:24 tch__ llaske, sounds good :)
19:25 theres something else I am interested in seeing,
19:25 mohayon I've got network troubles :/
19:25 mohayon has quit IRC
19:26 tch__ there will be many scenarios where activities will be deployed as standalone, would be great if we could have a set of basic UI "widgets" to allow collab in that scenario
19:26 mohayon <mohayon!~mohayon@87-231-208-31.rev.numericable.fr> has joined #sugar-meeting
19:26 abhinav tch__: point noted
19:26 tch__ ie., a basic widget to see the list of other shared instances with some sort of option to join,
19:27 mohayon Sorry, I've had some troubles with my Internet
19:27 llaske a way to send or receive invitation
19:27 tch__ it could be used by activities when running standalone and be disabled when running on something like sugarizer which provides a more richful view
19:28 but it would still be nice to have basic collab UI for standalone activities
19:28 llaske not sure it should be disable in Sugarizer because even in Sugarizer, activities are considered standalone
19:28 tch__ llaske, just an implementation detail :)
19:28 llaske, abhinav, walter_ mohayon opinions?
19:30 abhinav will it be same like in sugar i.e, a neighborhood view with the option to join?
19:30 tch__ abhinav, yes, it will be like a parallel client for the server, but the use case will be standalone activities
19:31 abhinav, I don't have any idea how it could look, btw, but should have a way to see other shared instances and join
19:31 llaske in the current Sugarizer implementation, the neighborhood view is just a bunch of call to the server to list current users and shared instance
19:32 tch__ llaske, exactly, it shouldn't make the server any more complex
19:32 llaske, but it would expand the server usefulness
19:32 abhinav tch__: Could you elaborate on "parallel client to the server" part?
19:33 tch__ abhinav, sugarizer neighborhood view is one client,
19:33 abhinav, this UI widget will act a client by itself, but design so it can fit into one activity
19:34 abhinav tch__: ok. Got it.
19:34 mohayon One thing important to me for sugarizer is the the way sugarizer send events for joining / leaving people
19:34 Today you have to rewrite code to know if sbdy join/quit
19:34 it's not hard
19:35 but could easily be rethinked
19:36 abhinav mohayon: +1. This can be done easily. The socket apis are rich enough to ease up this work I guess.
19:36 tch__ llaske, is there any documentation for the current "protocol"? ie., a diagram?
19:36 llaske, if not, abhinav think you could prepare one? will also be helpful to reflect your extensions/enhacements
19:37 llaske the only documentation is the one I've sent previously, other things is in the source code and in my mind
19:37 tch__: +1
19:37 I could help abhinav if you have any question
19:38 abhinav Sure. I ll try to share it with the community on my blog as the first article within 3-4 days.
19:38 llaske At the end of the document it will be nice to have the list of evolution/rewrite/update to do in the current implementation
19:38 so it will give you a good TODO list
19:39 abhinav llaske: point noted
19:40 llaske: I wanted to know that to what extent is the collaboration framework implemented in sugarizer?
19:40 is it just integrated with chat prototype. ryt?
19:40 llaske yes and in the neigborhood view
19:41 abhinav Cool.
19:41 tch__ llaske,  abhinav, one last thing from me :) I think Turtle Blocks would be representative use case to test this, and it shouldn't differ too much from mohayon's work
19:42 llaske to be honest I've never use collaboration in TurtleArt, what is possible with that: one turtle for each user on the same screen ?
19:44 abhinav: share the documentation you will write on Google App so I could update it
19:44 abhinav llaske: I guess Yes. and .tb file generated by a turtle is to be shared as far as my understanding says.
19:45 llaske: Sure. I will share it with you.
19:46 tch__ llaske, I am sure walter_ can provide a some ideas, in my opinion should be something basic, just enough to probe the whole collab "cycle" is in place :)
19:46 walter_ llaske, yes... each turtle is shared and you can share code
19:46 abhinav llaske, tch__  One question
19:46 llaske tch__: walter_: very nice
19:46 walter_ llaske, it is really fun... makes a nice multimedia chat too
19:47 llaske mohayon: take your XO with you, we'll test it that tomorrow :-)
19:47 mohayon Yes !
19:48 llaske abhinav: yes ?
19:49 abhinav walter_, tch__ How are we planning to collaborate in activities like TurtleArt. Sharing the .tb file after some fixed interval of time?
19:50 or we should use a real-time remote IPC to ensure the continuous flow of changes?
19:50 I m bit confused on this part.
19:51 Chat looks simple as we have send data on request
19:52 but in other activities, collaboration has to be done real-time
19:53 mtd <mtd!~martin@> has joined #sugar-meeting
19:53 mohayon I think that, each time you made a modification, you send the change onto the websocket. You should receive data the same way
19:53 If you enter the app, you'll receive the whole context
19:53 It should work on every app
19:53 llaske ? tch__ ?
19:54 llaske mohayon: guess that it the same thing for Paint, each update event will be sent
19:54 tch__ abhinav, I don't know the details of how it works in the python version, but the collaboration stack should provide a mechanism to share data (ie., serialized in json) and allow some kind of RPC to tell the other clients to exec that code
19:54 mohayon Yes, that's what we discussed about
19:54 tch__ abhinav, to me just looks like simple message passage
19:54 abhinav, in the most simple form, the "code" can be sent (as a message would be sent in chat) each time it changes
19:55 mohayon, there are different scenarios, sharing pre-joining state makes sense for TB or Paint, but it doesn't make much sense for something like chat
19:55 mohayon, collab stack should be flexible enough to allow both though,
19:55 llaske abhinav: may you could start by trying to implement a minimal collaboration in TurtleJS with the current Sugarizer implementation. It will give you a good overview of what works now and what need to be enhanced
19:55 may be
19:58 abhinav llaske , tch__ my point here is that as a user will add a block in TB, the same should be reflected to all the members of the group. ryt??
19:58 llaske it's my understanding
19:59 abhinav Following the suggestions made above, we will have to push update for every small change
19:59 tch__ abhinav, yes,
19:59 llaske a block change is not a small change
19:59 think to a mouse move in Paint !
20:00 abhinav llaske: yeah, by small I meant that small only. srry for wrong example
20:00 tch__ abhinav, what is important here is to think of a simple comm protocol that will allow these kind of scenarios
20:01 abhinav, ultimately it will depend on the imagination of the activity programmer to make a good use of it, but the examples will help to that
20:04 abhinav tch__, llaske I will start working on the common protocol then asap.
20:05 llaske nice. don't hesitate to ask me if you've got any question.
20:05 abhinav llaske Sure . I will keep all of you in loop.
20:05 tch__ has quit IRC
20:07 abhinav I m done from my side for the time being. :)
20:07 llaske Ok, guess we could close the meeting
20:07 tch__ <tch__!~tch@> has joined #sugar-meeting
20:08 tch__ abhinav, mohayon llaske sorry, ISP problem here now
20:08 mohayon, happens everywhere :)
20:08 abhinav Yeah Sure ... Only if tch__ is done I guess
20:08 tch__ abhinav, I am :)
20:08 mohayon :)
20:08 llaske I've just said that may be we could close the meeting :-)
20:09 tch__ considered closed  :)
20:09 thanks llaske abhinav mohayon for coming!
20:09 abhinav thanx a lot llaske tch__ mohayon for joining in :)
20:09 Good Night :)
20:09 llaske good night
20:10 llaske has quit IRC
20:10 mohayon Bye :)
20:10 mohayon has quit IRC
20:10 rohitsakala has quit IRC
20:26 abhinav has quit IRC
20:36 tch__ has quit IRC
20:50 tch__ <tch__!~tch@> has joined #sugar-meeting
20:55 tch__ has quit IRC
20:59 walterbender has quit IRC
21:00 walter_ has quit IRC
21:08 satellit_e has quit IRC
21:28 satellit_e <satellit_e!~satellit@2601:8:8800:99a:468a:5bff:fe31:faeb> has joined #sugar-meeting
21:36 walterbender <walterbender!~walter@146-115-134-246.c3-0.nwt-ubr​1.sbo-nwt.ma.cable.rcn.com> has joined #sugar-meeting
21:36 walter_ <walter_!~walter@146-115-134-246.c3-0.nwt-ubr​1.sbo-nwt.ma.cable.rcn.com> has joined #sugar-meeting
21:43 walterbender has quit IRC
21:43 walter_ has quit IRC
21:51 gonzalo_ has quit IRC
22:07 satellit_e has quit IRC
22:11 satellit_e <satellit_e!~satellit@2601:8:8800:99a:468a:5bff:fe31:faeb> has joined #sugar-meeting
22:41 tch__ <tch__!~tch@host-1-217.b12.cvc.com.py> has joined #sugar-meeting
22:47 walterbender <walterbender!~walter@146-115-134-246.c3-0.nwt-ubr​1.sbo-nwt.ma.cable.rcn.com> has joined #sugar-meeting
23:49 gonzalo_ <gonzalo_!~gonzalo@> has joined #sugar-meeting
23:53 gonzalo_ has quit IRC

 « Previous day | Index | Today | Next day »     Channels | Search | Join

Powered by ilbot/Modified.