KDE Plasma Educational Desktop GSoC 1st IRC meet

[karan pratap singh]

Hi all,

This is a log of an IRC meeting me( GSoC 2011 student ), Aleix, Aaron and
Marco had regarding KDE Plasma Educational Desktop GSoC.
This meet was basically to decide the goals of the GSoC and what
technologies could be used to implement them.

Any comments or suggestions are welcome and appreciated :)

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


from
Karan Pratap Singh
KDE Plasma Educational Desktop
IRC nick: kps_foo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20110511/eef157e9/attachment-0001.htm