Small hint for Plasma Classroom

[Aaron J. Seigo]

On Tuesday, September 14, 2010, Mario Fux wrote:
> Good morning
> 
> I'm following the things about Plasma classroom (because of time
> constraints I don't take a more active role) and as I was reading about
> the current ideas on the community wiki I wanted to leave a comment and
> decided to do it here.

feedback is quite welcome, and preferred on the mailing list for now. i find 
watching the comments section on individual pages a bit slow (or maybe it's me 
that's slow .. either way ;)
 
> About ''Plasma Classroom Network'': A local area network consisting of one
> leader system and one or more participant systems.
> 
> When you begin to implement this system please don't stand with "only one
> leader system" as a constraint as team teaching gets more and more popular
> in education (if one can afford it but that's another thing ;-).

this is actually one reason why i didn't called it the "teacher's system" :)

i'm not sure yet how i'd like to handle multiple "driving" systems. options 
include:

* allowing one leader system to hand the lead off to another leader system, 
causing the participant machines to connect to the other system

* allow "leader slaves" so that there is the one leader system, but other 
approved systems can be used to drive it

i'd really like to avoid having multiple leader systems at a time for a 
participant system as that is likely to complicate things quite a bit.

also note that since the classroom server (the database, really) will be 
separate from the leader system (though they could both be running on the same 
machine), this will make it easy to have multiple teacher computers all 
working on the same dataset.

i'd like to keep the participant systems going through the leader system as 
well as that allows the participant systems to be firewalled (or otherwise 
cut) off from the wide area network while the leader system isn't and can 
still access the classroom data that may be running elsewhere.

a lot of the answers will probably become clearer once the leader system GUI 
starts to come together in a definite form, as we'll then be able to decide 
exactly what features should be shared between multiple teacher systems.

but sending event data around is easy; sending out commends might be a bit 
more complex (would require a master/slave system for the teacher systems if 
staying with the one-leader-system design) but as long as we can assume that 
the teachers are cooperative and trusted to each other, then it becomes easier 
(we just have to authenticate the other teacher systems to the leader system 
once)

> BTW: For them who don't know me. I did the schooling as a primary teacher,
> study now education and computer sciences and thus have some good
> educational background.

for those who don't know Mario, he also holds kick ass dev sprints in the 
mountains of Switzerland :)

> BTW2: You'll use nepomuk for the "usage event information" of the
> participant plasma desktop?

for some of the events, nepomuk won't be very useful. one example use case 
(and yes, i need to put more use cases on the page... ):

Teacher says "Ok class, go to today's Math activity.."
Students start switching over, teacher watches their screen which shows 
besides each student's name which activity they are in, with a checkmark next 
to each one that is in the right activity.
Teacher says, "John, you haven't switched yet and we're all waiting for you. 
Can you please stop talking with Sally and do so now?"

other items, such as perhaps file access, may end up in nepomuk, however.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100914/b2d7d4b2/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100914/b2d7d4b2/attachment-0001.sig