Hi all,<br><br>This is a log of an IRC meeting me( GSoC 2011 student ), Aleix, Aaron and Marco had regarding KDE Plasma Educational Desktop GSoC.<br>This meet was basically to decide the goals of the GSoC and what technologies could be used to implement them.<br>
<br>Any comments or suggestions are welcome and appreciated :)<br><br>[00:10:55] <kps_foo> so shall we begin?<br>[00:11:00] <apol> sure<br>[00:11:08] <apol> let me start<br>[00:11:11] <kps_foo> ok<br>
[00:11:51] <apol> I think that the most important part of this project would be to provide to KDE some way to create the classroom abstraction<br>[00:12:39] <apol> we should identify what kind of data are we going to be sharing<br>
[00:12:46] <apol> and provide good infrastructure for that<br>[00:13:14] <kps_foo> ok<br>[00:13:34] <apol> synchrotron is good probably for some use cases, but we should make sure it's the correct way to go<br>
[00:14:33] <notmart> that was one of the two first ideas (i.e. remote widgets and syncrotron)<br>[00:14:46] <apol> in my opinion, we should use this gsoc as a kickstart for a new environment paradigm where the user (student using his computer) is not alone<br>
[00:14:54] <notmart> syncrotron seems a good async way to distribute files to sync configurations<br>[00:15:01] <kps_foo> notmart: +1<br>[00:15:04] <notmart> and doesn't need a perfect connection all the time<br>
[00:15:14] <apol> it's good, but it's 1 way<br>[00:16:29] <notmart> yeah, right<br>[00:16:32] <apol> also it's requiring quite some setup (it's php, probably needs a webserver and so? I don't know)<br>
[00:16:39] <notmart> what exactly would be needed for the other way?<br>[00:16:57] <notmart> yeah, any lamp would do<br>[00:17:07] <kps_foo> yup its php<br>[00:17:24] <notmart> (now still uses postgres, will have to change since kde infra doesn't haz it)<br>
[00:17:39] <kps_foo> mysql ?<br>[00:17:48] <apol> requiring that every classroom should have a lamp server is a bit overkilling, isn't it?<br>[00:18:25] <aseigo> apol: yes, it requires a webserver and is in PHP. it could trivially be rewritten in C++ or whatever using a Qt based http stack<br>
[00:18:38] <aseigo> (if that's a real issue :)<br>[00:18:49] <aseigo> it certainly isn't rocket science, which is the nice thing about it<br>[00:19:20] <aseigo> (it literally took me 1.5 days to write and test, and ~2 days of not-full-time-efforts to work out various kinks that were reported and features requested)<br>
[00:19:51] <aseigo> also remember that "lamp server" runs just fine on a laptop..<br>[00:19:54] <aseigo> or a netbook, for that matte<br>[00:19:55] <aseigo> r<br>[00:20:05] <apol> runs fine, but it's a pain in the ass to setup<br>
[00:20:16] <apol> or well<br>[00:20:19] <apol> runs fine, but it's a pain in the ass to setup _properly_<br>[00:20:24] <aseigo> certainly harder than a built-in solution<br>[00:20:42] <aseigo> a built-in solution is not going to be as scalable, but that isn't an issue here<br>
[00:20:49] <apol> what kind of data would we share there? lessons?<br>[00:20:57] <notmart> $educationaldistro could have it already setted..<br>[00:21:02] <aseigo> kps_foo: have you read the <a href="http://community.kde.org">community.kde.org</a> page about plasma classroom?<br>
[00:21:12] <kps_foo> yes long time back<br>[00:21:15] <apol> notmart: requiring less from distros is good generally<br>[00:22:06] <kps_foo> I also read about a Meduxa project on the wiki<br>[00:22:11] <aseigo> things that are most often requested are:<br>
[00:22:23] <aseigo> * sets of files (possibly templates, but that's a detail)<br>[00:22:32] <aseigo> * set of applications to launch (possibly with pre-configurations)<br>[00:22:58] <aseigo> * sets of plasmoids (they, or their equivalents, are used in both the portugal and brazil deployments)<br>
[00:23:13] <apol> how would the student report back to their teacher?<br>[00:23:14] <aseigo> essentially, pre-configured activities<br>[00:23:15] <kps_foo> maybe also instant chat with the teacher ?<br>[00:23:23] <kps_foo> aseigo: exactly<br>
[00:23:26] <apol> plasmoids should be installed by the distro... no?<br>[00:23:30] <aseigo> i don't know if chat is useful, tbh, in a classroom<br>[00:23:56] <apol> well, we need to be able to send the results back to the teacher<br>
[00:24:08] <kps_foo> apol: yeah<br>[00:24:13] <aseigo> apol: not necessarily.. and this is about configuration as well.. even if the plasmoids already exist on the student systems, something needs to say "start the parley plasmoid, place it over there and load that language file"<br>
[00:24:49] <apol> aseigo: sure, but that's a configuration, not a plasmoid...<br>[00:24:50] <aseigo> right .. so .. results .. this is something i think would be best implemented in the "classroom containment" which would be a full-screen (aka "desktop") containment<br>
[00:24:50] <apol> no¿<br>[00:25:33] <apol> but that wouldn't make it possible for applications to integrate with that<br>[00:25:38] <aseigo> apol: yes, that's configuration; so is which applications and possibly even which files (they may already be on the system or on a network drive)<br>
[00:25:56] <apol> yes<br>[00:25:58] <aseigo> there's also the possibility of scripted plasmoids living on the teacher's system that are distributed<br>[00:26:03] <aseigo> which makes it not just configuration in this case<br>
[00:26:14] <apol> well, teachers don't want to write code generally...<br>[00:26:25] -*- aseigo can imagine having "template" plasmoids written in javascript that the teacher can "configure" and then deploy<br>
[00:26:33] <apol> but yes, if we can do files, we can install scripts, of course<br>[00:26:34] <aseigo> nah, don't have to.<br>[00:27:03] <aseigo> imagine a "math test plasmoid" that includes the math questions entered by the teacher earlier<br>
[00:27:21] <aseigo> would be very easy to create a front end to such a thing that would require zero coding, packaging, etc.<br>[00:27:26] <aseigo> a plasmate for teachers, if you will :)<br>[00:27:52] <aseigo> ditto for future kde applications written with QtQuick; those could be deployed on demand quite easily<br>
[00:28:06] <aseigo> anyways.. delivery is just files, yes<br>[00:28:22] <apol> yeah well, let's consider plasma as a shell for the moment<br>[00:28:29] <aseigo> the basic configuration is probably most easily done using Plasma Desktop Scripting files (so they can automatically adapt to screen resolutions, etc)<br>
[00:29:01] <apol> also something very important is how we would setup the classroom<br>[00:29:07] <aseigo> the containment is a good candidate (though not the only one, certainly) for housing both the layout fetching/display and the feedback to the teacher<br>
[00:29:37] <aseigo> apol: could be done perhaps via this theoretical classroom containmen<br>[00:29:38] <aseigo> t<br>[00:29:51] <apol> aseigo: specifying the teacher IP?<br>[00:29:53] <aseigo> the teacher system could either announce via zero conf, or the containments could be preconfigured<br>
[00:30:12] <aseigo> IP, host name, zeroconf ...<br>[00:30:16] <apol> I think preconfigured will tend not to work<br>[00:30:20] <aseigo> the containment could include a small "log in" prompt<br>
[00:30:20] <apol> zeroconf would be great<br>[00:30:30] <kps_foo> there could be a default configuration in case the teacher's system is not working?<br>[00:30:34] <aseigo> (we will already use zeroconf elsewhere in libplasma, so shouldn't be a stretch)<br>
[00:30:59] <aseigo> kps_foo: could just say "waiting for teacher system" and refuse to do anything else :)<br>[00:31:11] <apol> kps_foo: let's forget about defaults for the moment...<br>[00:31:16] <kps_foo> ok<br>
[00:31:36] <apol> ok, then, getting back at teacher feedback<br>[00:31:41] <aseigo> ah, and to be extra clear on the shell aspect: i suggest just usng plasma-desktop as the shell .. it has all the features needed and all the extra bits are easily made innaccessable as they are all triggered using plugins<br>
[00:31:57] <aseigo> right, so that'll be the Big Part(tm) of this imho<br>[00:32:10] <aseigo> there needs to be a server implementation at the teacher's system<br>[00:32:29] <aseigo> the students need to "log in" to the system, and the teacher can do the auth (much like a web app, really)<br>
[00:32:33] <apol> aseigo: he will receive it using synchrotron? how?<br>[00:32:53] <apol> or just post to the http server?<br>[00:33:12] <aseigo> can be http; could be XMPP; protocol is almost secondary<br>
[00:33:27] <aseigo> the teacher's system needs to be able to:<br>[00:33:38] <aseigo> * list which students are logged in, and which activity they are currently using<br>[00:33:48] <apol> agree<br>[00:33:52] <kps_foo> +1<br>
[00:33:54] <aseigo> * provide feedback as to what they are doing (e.g. which application is launched, etc.)<br>[00:34:00] <apol> that's why I was thinking about telepathy<br>[00:34:23] <apol> this would mean that edu applications would be able to use what has been setup<br>
[00:34:30] <aseigo> telepathy might be overkill (i'm a little sceptical of the API), but sure .. it could definitely work<br>[00:35:07] <apol> well, it's the only thing we have KDE-wise<br>[00:35:10] <aseigo> what would be very interesting is to find out how the nepomuk event stuff is going<br>
[00:35:13] <aseigo> notmart: how is it? :)<br>[00:35:37] <notmart> spitted some blood on it today<br>[00:35:43] <aseigo> because if that is ticking along quickly enough (might be due to contour) then the containment could just forward on those events via xmpp to the teacher system<br>
[00:35:54] <aseigo> then the edu apps, etc. could just register events<br>[00:36:07] <notmart> basically it logs what resource is open/modified/closed by which application<br>[00:36:10] <aseigo> that would avoid close coupling of the edu apps and plasma classroom, for instance<br>
[00:36:26] <notmart> after having that one can infer all kinds of crazy things<br>[00:36:27] <apol> sure<br>[00:36:31] <apol> we don't want coupling<br>[00:36:32] <aseigo> notmart: how feasible would it be to add a "current app" log?<br>
[00:36:33] <notmart> (note as of today is still not really working)<br>[00:36:39] <apol> schools will want to use openoffice<br>[00:36:46] <apol> (or libreoffice XD)<br>[00:36:48] <aseigo> apol: yeah..<br>
[00:37:02] <aseigo> we can track the current app with KWindowSystem and/or libtaskmanager fairly easily though<br>[00:37:07] <aseigo> and send that info to the teacher<br>[00:37:20] <notmart> hmm, not sure about that, ivan would be more the man for it<br>
[00:37:22] <aseigo> technically, what i'd recommend is that the classroom containment becomes responsible for that.<br>[00:37:32] <notmart> at the moment is centered about resources<br>[00:37:48] <notmart> so what file open or whatever can be mapped in a nepomuk resource<br>
[00:37:50] <aseigo> and a Plasma::Service is written that implements the send-the-messages-to-the-teacher-system as well as the authentication<br>[00:37:59] <apol> well, the important thing is to have the channel to provide all this information<br>
[00:38:06] <aseigo> then the Containment can use the Service and funnel all the informatoin we wish to the teacher<br>[00:38:17] <aseigo> the teacher system would then have one connection open per student<br>[00:38:17] <apol> the specific information is not that much of a problem, by now<br>
[00:38:40] <aseigo> and this is an important point: the connection needs to be kept alive and ping the teacher system every so often (e.g. every 1-10 seconds)<br>[00:38:41] <apol> if we limit it to such small use cases we will be limited in the future<br>
[00:38:59] <apol> aseigo: or just use a stateful protocol to communicate<br>[00:39:01] <aseigo> this is a requested feature, apparently: to know if a student has been naughty and unplugged the network cable to try and avoid being watched ;)<br>
[00:39:18] <aseigo> no, apparently we need to "heartbeat" the student systems<br>[00:39:33] <apol> aseigo: xmpp knows if a client is down<br>[00:39:42] <aseigo> perfect then :)<br>[00:39:55] <kps_foo> agreed<br>
[00:39:56] <aseigo> so should we add xmpp as a part of the design specifics? kps_foo: what do you think?<br>[00:40:00] <aseigo> perfect :)<br>[00:40:16] <kps_foo> :)<br>[00:40:35] <apol> problem with xmpp is that libraries are a pain in the ass (used it some in the past) that's why I proposed to use telepathy<br>
[00:40:59] <apol> probably kps_foo should find the best way<br>[00:41:10] <aseigo> a containment with a service that connects to a teacher app (can be a stand-alone KDE app; not necessarily plasma-desktop or plasma anything ..), speaks XMPP, notes disconnects, does auth (at first can be "fake" auth) would be a great start<br>
[00:41:25] <aseigo> apol: yes, i agree that that is a good starting task indeed<br>[00:41:26] <apol> that would be awesome<br>[00:41:45] <apol> that way we would have the abstraction we need set up<br>[00:41:59] -*- aseigo nods<br>
[00:42:00] <aseigo> step 2 could involve sending pre-configured layouts from the teacher to a student containment<br>[00:42:02] <apol> and start worrying about gettign it properly integrated with the desktop<br>
[00:42:04] <kps_foo> got it<br>[00:42:16] <aseigo> step 3 could be forwarding nepomuk events<br>[00:42:50] <aseigo> step 4 could be augmenting kde edu apps to log such events, and include a "current window" logger as well (could be in the containment itself)<br>
[00:42:59] <aseigo> if that was managed, that would already be kick ass..<br>[00:43:14] <kps_foo> understood<br>[00:43:24] <aseigo> having a way to set up pre-configured layouts visually would be another fine step<br>
[00:43:35] <aseigo> apol: what do you think? anything to add, remove, re-arrange?<br>[00:43:48] <apol> i think it's good<br>[00:43:52] <kps_foo> me too<br>[00:44:05] <apol> aseigo: what will be teh first kde to support proper qml plasmoids?<br>
[00:44:15] <aseigo> apol: 4.6.0 :)<br>[00:44:38] <apol> hahaha<br>[00:44:39] <apol> good<br>[00:44:41] <aseigo> notmart has done some awesome work there<br>[00:45:01] <notmart> uuh, on what? ;)<br>
[00:45:11] <notmart> ah, qml plasmoids<br>[00:45:55] <aseigo> notmart: yes, you're favourite thing in the world ;)<br>[00:46:10] <kps_foo> :-)<br>[00:46:42] <aseigo> er, your favourite<br>[00:46:50] <aseigo> kps_foo: how do you feel about that?<br>
[00:47:02] -*- notmart hoped to be your favourite thing in the world :p<br>[00:47:05] <aseigo> kps_foo: too much, too little, just right, exciting, boring, pink, fluffy?<br>[00:47:15] <apol> kps_foo: I think that the very interesting part about this gsoc is that if the classroom abstraction is done properly, we can probably adapt it to other use cases quite easily in the future<br>
[00:47:22] <aseigo> apol: agreed<br>[00:47:22] <kps_foo> exciting<br>[00:47:37] <apol> in the end the classroom is just an abstraction for "some people working together and exchanging stuff"<br>
[00:47:48] <kps_foo> apol: +1<br>[00:48:42] <kps_foo> it could well be extended to Plasma Office or something like that ?<br>[00:48:47] -*- notmart thinks the difficult and awesomio thing here is the sharing protocols<br>
[00:49:07] <notmart> a shell can come after, that by itself is not the awfully time consuming process it used to be<br>[00:49:14] <notmart> even tough not to be undersestimated<br>[00:49:18] <apol> kps_foo: thign is you will be touching many technologies, so don't be afraid to ask us or to look for the right guy (tm)<br>
[00:49:31] <apol> notmart: agree<br>[00:49:38] <kps_foo> oh I will ask a lot thats for sure :D<br>[00:50:15] <kps_foo> should we place a log of this IRC meet on the MLs ?<br>[00:50:35] <notmart> think is a good idea<br>
[00:50:57] <apol> sure<br>[00:50:57] <aseigo> kps_foo: and please feel free to start pages in the <a href="http://community.kde.org">community.kde.org</a> wiki and what not<br>[00:51:11] <kps_foo> aseigo: ok, got it<br>
[00:52:02] <kps_foo> now 1 last thing I wanted to tell everyone.....<br>[00:52:06] <aseigo> (and to use any other part of our infrastructure too .. it's all there to make you go, go, go! :)<br>[00:52:16] <kps_foo> aseigo: ok<br>
[00:53:15] <kps_foo> Its just that I got semester exams from 14th May to 27th May....I will have small pockets of time in this period during which I will try to research as much as I can about the technologies to be used<br>
[00:53:42] <kps_foo> but I can start full time coding only from 27th May<br>[00:54:35] <kps_foo> so till 27th May....I will be researching the protocols.....will be mostly absent from IRC....but will be able to reply to emails once or twice in a day..<br>
[00:55:03] <kps_foo> is that ok?<br>[00:55:05] <aseigo> kps_foo: email is fine; you can email any questions you have to the relevant mailing lists<br>[00:55:06] <apol> kps_foo: it's ok<br>[00:55:17] <aseigo> kps_foo: you can also send mail to use directly, of course, but the lists are usually better<br>
[00:55:22] <apol> community bounding ends by end of may so it's pretty good already<br>[00:55:23] <aseigo> more people, doesn't get lost as easily, etc.<br>[00:55:50] <kps_foo> Ok, got it , thanks! :)<br>
[00:56:38] <kps_foo> so this concludes the meet, then ?<br>[00:56:45] <apol> yep<br>[00:56:55] <kps_foo> ok<br>[00:57:04] <aseigo> great :)<br>[00:57:05] <apol> kps_foo: keep us up to date with your research, thoughts and conclusions<br>
[00:57:08] -*- aseigo waves....<br>[00:57:09] <-- aseigo (~aseigo@kde/aseigo) has left #kde-classroom<br>[00:57:11] <kps_foo> ok<br>[00:57:13] <kps_foo> :)<br>[00:57:19] <kps_foo> definitely<br>[00:57:25] <apol> it's better to make sure that when you start we're on the same page<br>
[00:57:29] <apol> tahn backtracking<br>[00:57:36] <kps_foo> ok<br>[00:57:38] <kps_foo> got it<br>[00:57:49] <kps_foo> no code until I get the go ahead from you all :)<br>[00:58:17] -*- kps_foo is placing a log of this meet on MLs<br>
[00:58:22] <apol> :)<br><br><br>from<br>Karan Pratap Singh<br>KDE Plasma Educational Desktop<br>IRC nick: kps_foo<br>