« 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![]() |
|
02:18 | gonzalo_ has quit IRC | |
09:48 | satellit_e has quit IRC | |
09:48 | gonzalo_ <gonzalo_!~gonzalo![]() |
|
09:59 | satellit_e <satellit_e!~satellit![]() |
|
10:42 | satellit_e has quit IRC | |
10:46 | satellit_e <satellit_e!~satellit![]() |
|
11:07 | meeting <meeting!~sugaroid![]() |
|
13:19 | walterbender <walterbender!~walter![]() |
|
13:19 | walter_ <walter_!~walter![]() |
|
13:46 | tch__ <tch__!~tch![]() |
|
14:47 | rohitsakala <rohitsakala!uid32931![]() |
|
16:28 | jo0nas has quit IRC | |
16:29 | jo0nas <jo0nas!jonas![]() |
|
17:48 | tch__ has quit IRC | |
18:44 | tch__ <tch__!~tch![]() |
|
18:47 | abhinav <abhinav!dce39556![]() |
|
18:51 | mohayon <mohayon!~androirc![]() |
|
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![]() |
|
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![]() |
|
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![]() |
|
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![]() |
|
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![]() |
|
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![]() |
|
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![]() |
|
21:36 | walterbender <walterbender!~walter![]() |
|
21:36 | walter_ <walter_!~walter![]() |
|
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![]() |
|
22:41 | tch__ <tch__!~tch![]() |
|
22:47 | walterbender <walterbender!~walter![]() |
|
23:49 | gonzalo_ <gonzalo_!~gonzalo![]() |
|
23:53 | gonzalo_ has quit IRC |
« Previous day | Index | Today | Next day » Channels | Search | Join