hypothetically speaking...

[kmj]

suppose some lazy pseudohacker were to (hypothetically) get off his lazy ass and stop watching food TV long enough to write a program.

Let's say this program were an online classroom that this guy (or girl) decided to write because he knew of a friend (who may or may not live in a state known for its Sunshine) who might be in such a position where said program may be handy.

We can assume this pseudohacker would be using Python since it seems only apt that a pseudocoder write in pseudocode...

Now, if you will, allow me to pose a few questions regarding the above scenario.. (have I lost you yet?)

1) Do you think anyone would consider helping this lonely hax0r? would you?

2) Wouldn't this be a wonderful opportunity for certain l33t hackers who currently don't hack pseudocode (aka, Python) to learn it? (because, I'm sure you'd agree, there are many who've been meaning to try it out)

3) What kind of features would this hacker put in the program? there'd have to be some kind of group chat, with the teacher as a kind of mod, sure.. but there must be more that would be handy... imagine a chalkboard? that'd be cool..

4) What would the interface look like. Would he use Qt, glade? Hmmm..

5) On the abstract level, what would the design look like? client/server? p2p? ..


I bet you're nearly as interested as I am.

Seriously, I think this is a great idea for a project, and one that I may at some point actually get around to starting.. If anyone else likes the idea and would like to help out, that'd be groovy. If my prior style of discussion was rather obtuse in your mind, let me know and I'll be more to the point. Right now, its really in the "idea" phase, but I think it's a great idea.. Please let me know if you're interested..

oh, and be interested. be very very interested.

[Bradmont]

that sounds kinda cool, I especially like the chalkboard idea. I think for something like that, it'd be best to do client-server, because peer to peer would probably be somewhat difficult to coordinate with group chats (though it does present some interesting possibilities...)

and, of course, python r0x0rz! :)

[l01yuk]

I would be interested in this, I was thinking of learning python and I too know someone who could do with something like this.

I agree with Bradmont that it should be server/client. It would probably need a chalk-board, file transfer and perhaps viewing, chat, messaging so messages can be queued in case they are not logged on and file storage for class materials.

It would be good if the students could connect out of class hours to study as a group with access to the class materials as well.

Anyway, a couple of ideas from me. Post some more details, what does this (possibly) sunshiny (possibly) person want from the app and who is their target audience?

[Jhonas]

Hm. I'd do it, if it weren't for the fact that you probably don't want someone who hasn't the scheduled computer work time type thing. I'm on at weird times, usually after 2am EST. But... anyway. I'd like to learn a highly versatile and... awesome language such as Py. Alas, I would prefer to work on my Win2k box. But... if needed, (you DID say Qt,) I can work on my Linux box or this machine that might get Debian installed onto it if I can find a good netinst.

So in otherwords, I'm willing, but I don't know if I am the type you're looking for.

[Jhonas]

I have some questions.

Now, would it be better if there was a server app that you could run off a command line (if you have a virtual web server with bash or whatever) that everyone could log into? And one person could be the teacher/mod/whatnot? That way you could make GUIs for all of the clients. Think NWN.

[darelf]

Originally posted by Jhonas
Think NWN.

I think that bit is the best advice to give anyone.

Seriously, this what I am currently working out in my head (although some people may know that I'm doing it for gaming rather than classroom, but the pieces are all the same).

In fact, I wouldn't mind just working on your version and then adapting it for gaming later on.

1) It should include chat facilities. Colorized, hyper-link capable, server-logged (so that you don't worry about connection drops).

2) It should include "shared-space", you used to the word "chalkboard". Basically a canvas-type area that is shared. Using "cut-outs" (sprites) would make it easier for non-artistic type people to use.

3) It should include stored information that can be categorized. XML is excellent for document storage and categorization. A tree-view is a great way to view XML structure while on-line.

4) Messaging. It should include the ability to transfer documents, private messages, etc. XML is also an excellent communications means for this type of messaging.

5) Rooms. A single server could handle multiple "classrooms"/"labs". Each room could have a "teacher" or "mod". (sort of IRC-like)

More?

BTW, just point me towards danger! Let me know what part to work on and I'm there (if you're doing the organizing, which I think you ought to).

Also, my vote goes to Qt. (I'll take any GUI except Tk)

EDIT:
Jhonas, why not LFS or Gentoo?
It seems more developer friendly than a 'pre-compiled package' system.

[stuka]

Sounds interesting. I took an online class last summer (Psych :)), and it was set up with some features like that - there was group chat (available 24/7, and logged, so those that missed discussions could still benefit from it), a grade book section (so students could check grades online), but there wasn't a chalkboard, which would've been nice, and added an element of real teacher interaction/illustration. BTW, I'd be willing to help, but quite frankly, I'm no Pythonista...I prefer the "barbaric" world of C/C++...;)

[inkedmn]

you KNOW i'm into it :)

[kmj]

Cool; good to see some positive responses... I'm pretty optimistic about this project, as I'm starting to get a more solid idea of how it will work.

Okay, I'm listing all of you guys down as potential developers... :)

Definitely, I've decided on client-server, and I spend a few minutes last night reading over python's SocketServer and asyncore modules. I'll probably end up using SocketServer, but I haven't written a multithreaded server before.. (which I'm sure this would need to be).

I also vote for Qt over Gtk... three reasons I can think of:

+I'm more familiar with it
+ It's inherently object oriented (not certain makes a big difference)
+ Qt Designer - a drag&drop GUI creator which at minimum means a speedy prototype
+ I just last night ordered a book on PyQT which cost $50. Incidentally, that book is free online at http://www.opendocspublishing.com/pyqt/


Okay... for those of you who haven't programmed with Python before; trust me, I can 99% guarantee that Python will be the easiest language to learn you've seen. Just accept it's dynamic nature.

Stuka: You say you're not a Pythonista.. does that mean you don't use it, or you're not fond of it?


As for the interface; this is what I've thought of so far:

-Two chat windows, one for all students, and one for the teacher.
-A class-list, which has name, status, "hand-up", whatever else we can think of...
-The chalkboard, which can be either text or drawing; I'm sure we could do either or both with some effort
- A "file-viewer" for handouts.

Currently, I'm seeing this as several panes docked in a single MainWindow, but we could do it as seperate windows, too.

Okay, I'll respond more in a bit.. We're definitely still in the brainstorming phase, so please post any ideas you might come up with!

[kmj]

A couple other things:

Jhonas: you can run it on windows. I want to make sure that this runs in both windows an linux.

Okay, I'm going to incorporate your ideas and make two new posts here: 1 with developers and 1 as a "brainstorming chalkboard". As people join/quit and ideas are presented, I'll just edit those posts. That'll keep this thread a bit cleaner.


Once we get going, I'll consider making a sourceforge project. I don't want to do that yet, since I think sourceforge is overrun with SIDS (yes, sudden infant death syndrom). I did a search there for classroom, and there are about a half-dozen projects which haven't been touched since they were created.

[kmj]

If there are any errors in the below list, please let me know! (You can PM me, so as not to "pollute" this thread. :) )

leaders
kmj (that's me)

Developers
Bradmont
*l01yuk
*Jhonas
darelf
*Stuka
inkedmn
Strike



* - you are currently unfamiliar with Python.

Python resources, for those who want to learn more:
The Python Tutorial (http://python.org/doc/current/tut/tut.html) is perfect for those who already know how to program
How to Think Like a Computer Scientist - Python (http://www.ibiblio.org/obp/thinkCSpy/) for those who have yet to learn programming

If you want to be added to the list, let me know.

Also: if anyone is interested enough in this project to become a leader, PM me, since I'd like it if at least one other person assumed leadership responsibilities. I expect that it should fall on the leaders' shoulders to get (and keep) the project going, mostly by example. So yeah, being a leader requires a little more commitment than just being a developer.

[inkedmn]

Originally posted by kmj
As for the interface; this is what I've thought of so far:

-Two chat windows, one for all students, and one for the teacher.
-A class-list, which has name, status, "hand-up", whatever else we can think of...
-The chalkboard, which can be either text or drawing; I'm sure we could do either or both with some effort
- A "file-viewer" for handouts.



some very good ideas...

maybe implementing FTP for the file transfer portion...

[kmj]

---Implementation---
python
Qt (or GTK)
client/server (TCP)

possibly a modified Jabber or IRC server


---Features---

Client

Chat Windows
- possibly seperate one for teacher
- private messaging
- hyperlinks
- server logging

Class List
- name
- status
- "hand-up", kind of like "voice" in IRC

Chalkboard
- text
- drawing
- sprites
- shared-space (same thing?)

Handouts
- file viewer window

After-Class Access

Server

School
- handle multiple classrooms

Command Line

Logging


---Notes---

darelf - can you be a little more specific about "include stored information that can be categorized"? I'm not sure what you mean.

As people post ideas, I'll edit this post.

[stuka]

kmj - I mean I'm mostly unfamiliar with it. I've got copies of it here @ work and @ home, but haven't used it - in part because of work and school (both requiring programming, and most of the work being done in C or C++). Heck, I'll jump in, but due to time constraints now, I'd rather code small bits rather than design - plus I'd sorta like to watch other people do design work (I'm CERTAIN to learn something!).

[darelf]

"Shared space" would be like a chalkboard, but that everyone can use. This may be just a mode for the chalkboard.

"categorized information"...
I think you mention 'handouts', which is the same kind of thing. We ought to have documents that can be transferred back and forth, viewable and printable from within the program. So you wouldn't want to just transfer excel sheets or pdfs, you would want an easily editable document. And you want the program to view them in-place, and also be able to print them out.
By 'categorized', I mean that you might want to sent the entire course schedule and then add pieces as you go along. Thus the 'document' has sections that can be dynamically updated in-place.

<class>
<chapter name='Stuff you don't know'>
<stuff/>
</chapter>
<chapter name='Stuff you still don't know'>
<stuff/>
</chapter>
</class>

You can insert bits of document into such a structure. And allow the fragments to be independantly displayed within the program.


Does that make sense? (I am hardly clear, most days)

[kmj]

Okay, I have more of an idea of what you mean.. I think we can hash it out more as we go along.

So we definitely want to have some kind of "File Viewer", aka handouts. It sounds like you want us to come up with our own format.. like a text document, perhaps with embedded images; rather than embedding a pdf, doc, ps, (etc) viewer into the program. Either way should be doable, but it may be easier if we have our own..

Initially I was thinking of making it just a viewer (ie; read-only), but it seems like a good idea to let users annotate their handouts. We could keep it quite simple.. probably do it in XML.

[darelf]

Oh BTW, I may have really lame ideas that I nonethless express... so feel free to just say "no" if something isn't in the direction other people think it ought to be.

I certainly don't want to go on a wild-hare over some idiotic feature.

[inkedmn]

is there going to be a local program on the "student" machines? is the software for the teacher and student going to be the same?

[Dru Lee Parsec]

1st of all, This would be way fun to code but I have absolutly no spare time to spend helping out :(

Next, I know there is at least one freeware version of this software that runs on Linux but I cannot for the life of me remember what the name of the program is. So if the purpose of this program is to build a tool for your friend then you should spend your time researching existing software. However, if your goal is to write some cool code then go for it!

You know what, I even interviewed for a job (about 3 years ago) with a company that writes this kind of software. I can't even remember what the company's name was.

Gosh. This posting was almost no help at all !

[kmj]

Dru: actually this project is rather related to you.. :) since you're helping inkedman out.

I did look at sourceforge, and there are about 4 dead-in-the-water (apparently) projects with the same goals. If you do find any other freeware programs, post the links, please. :)

inked man: right now, I see the teacher(s) and student(s) running pretty much the same client, though there is a good possibility that down the road, they'd diverge to be more specialized. In fact, most likely they will.

And yes, I definitely see this as having a local program, rather than any kind of web-based interface or anything.

[stuka]

Of course, if we were feelin' really frisky, we could make sure and specify the architecture so that clients could be written in any language, so we could have another "As Many Languages As We Can" thread!

[kmj]

heh; good idea! Well, we should have a well defined protocol anyway. :)

[Bradmont]

A couple ideas,

1. Why not build on an existing protocol, eg IRC or Jabber (I think it might be fun with Jabber). The Jabber spec is totally open, and we could enhance it in any way(s) we see fit, plus we gain the advantage of not having to write the server from scratch.

2. Modularity. kmj, you've done some work on moobot, and seen how easy it is just to plug in a module and go. Getting the framework working takes some time, but once that's done, it makes additions super-easy. Fer instance, when a module is imported and instantiated, it could do something like create a pane/panel/whatever QT uses and the framework would stick it into a tabbed pane/notebook (I'm using some Swing and GTK terminology here, since I've never looked at QT).

3. I'd rather not use QT. :) I am reasonably comfortable with GTK, and the python GTK bindings are quite nice, and Glade makes GUI design super-easy. I am flexible on this, but I'm not a big fan of QT in general (I don't think I've even got it installed, and I think it's kinda fugly).

4. If we do end up doing the server from scratch, we should take a look at the "Twisted" framework, that's what it's there for :)

[Bradmont]

Ooh, all this coming up with our own protocols/formats/etc, it's just a bunch of unnecessary work :)

You were talking about creating our own document type for images/text/etc, again, why not use an existing format, something like SVG?

[darelf]

I'm up for anything Bradmont.... but...

Where's the fun in that?

We don't write compilers in class because no one has compilers. I mean, come on.... if I was doing this for work, I could see your point.

Anywayz, I'm sure there's enough stuff to do anyway so I'm not very picky. (and I think Qt is beautiful compared to GTK, but it's just a personal opinion)

[Jhonas]

Okay, all sounds good, but I always seem to know less than I'd like myself to know. . . but I must make inquiries for clarification:

1) I know Qt works on any platform pretty much (X, Win, Mac(?), etc), but does Gtk? I've only seen Gtk close to Linux/X-related things.

2) Doesn't non-X (like Windows) Qt SDK cost some money?

I'm just barely getting into the programming frame of mind, so that's why I offered to help. I know just enough PHP to work with databases and such and I did know enough perl to make a chat server type thing, but I forgot it already (pretty sad, huh?).

Bare with me. Please.

[kmj]

1. Why not build on an existing protocol, eg IRC or Jabber (I think it might be fun with Jabber). The Jabber spec is totally open, and we could enhance it in any way(s) we see fit, plus we gain the advantage of not having to write the server from scratch.


I could probably go with this... I'm not 100% sure how it'd work out.. I did think about some how just using the irc protocol, but I guess it's harder for me to wrap my mind around this methodology than building things from scratch. I guess I don't know enough about it, or haven't thought enough about it to be sure that it would be suitable.


2. Modularity. kmj, you've done some work on moobot, and seen how easy it is just to plug in a module and go. Getting the framework working takes some time, but once that's done, it makes additions super-easy. Fer instance, when a module is imported and instantiated, it could do something like create a pane/panel/whatever QT uses and the framework would stick it into a tabbed pane/notebook (I'm using some Swing and GTK terminology here, since I've never looked at QT).


Modularity is an interesting idea.. I'm not 100% convinced that it would be as applicable, but it would certainly make it very much easier to enhance the program later on. (I'm sure you'll agree that moobot practically screams modularity.. while I see it benefitting this, I don't see it standing out so much.) Definitely something to consider, and likely apply. I see how this would help, for example, the fileview area.. you could kind of support plugins for any types of files, tiff, pdf, etc.


3. I'd rather not use QT. I am reasonably comfortable with GTK, and the python GTK bindings are quite nice, and Glade makes GUI design super-easy. I am flexible on this, but I'm not a big fan of QT in general (I don't think I've even got it installed, and I think it's kinda fugly).

Do you think the GUI of Qt is fugly, or the implementation? I'm willing to at least look at glade, but I just got Qt-designer and that seems quite nice. I'll try glade out, too, and see how I feel about that. Jhonas has a point that Qt is cross-platform; I'm under the impression GTK isn't? That's a huge selling point for me.. We can talk about this more.


4. If we do end up doing the server from scratch, we should take a look at the "Twisted" framework, that's what it's there for

I have no idea what the "Twisted" framework is.. can you explain it, or provide a link for me? Thanks.

Jhonas:
Only for commercial programs. Non-commercial programs are free (http://www.trolltech.com/developer/download/qt-win-noncomm.html)

[kmj]

Bradmont: I don't suppose you could provide linkage for any python/glade/gtk resources? I just apt got the python-gtk and python-glade packages, so I'll start trying to play with it...

[Bradmont]

twisted: http://twistedmatrix.com/products/twisted

I think there is a gtk port for windows, but I'm not too sure. I do know that the gimp has been ported to windows, I'd have to do some googling.

One disadvantage to using GTK with python is that there isn't a whole lot of documentation for those specific bindings. You pretty much have to use the C++ API documentation, and example python code, but once you get used to it, it's not so bad.

[recluse]

No Mac? Seems like that's a fairly major player too, esp in the edu setting with the inexpensive iMacs.

[Bradmont]

we could do a java client, and cover everybody that way.

[vomjom]

Originally posted by kmj
Definitely, I've decided on client-server, and I spend a few minutes last night reading over python's SocketServer and asyncore modules. I'll probably end up using SocketServer, but I haven't written a multithreaded server before.. (which I'm sure this would need to be).

Nope. In fact, it might be better single-threaded.

I also vote for Qt over Gtk... three reasons I can think of:

+I'm more familiar with it
+ It's inherently object oriented (not certain makes a big difference)
+ Qt Designer - a drag&drop GUI creator which at minimum means a speedy prototype
+ I just last night ordered a book on PyQT which cost $50. Incidentally, that book is free online at http://www.opendocspublishing.com/pyqt/

Well, to be honest, you aren't going to be able to do much with Qt Designer or glade for this program, because the only hard part of the GUI is making the chalkboard (which isn't that difficult). The only features I can think of for one right now are: Typing-mode. Chalk mode. Eraser.
The GUI certainly isn't the hard part, and the choice between QT and GTK+ is an unimportant one (you can always change later with minimal effort).
Either way, both work in windows.

Okay... for those of you who haven't programmed with Python before; trust me, I can 99% guarantee that Python will be the easiest language to learn you've seen. Just accept it's dynamic nature.

"Easiest language to learn you've seen" is a bit far-fetched, isn't it? Python is a good choice, though :)

-Two chat windows, one for all students, and one for the teacher.
-A class-list, which has name, status, "hand-up", whatever else we can think of...
-The chalkboard, which can be either text or drawing; I'm sure we could do either or both with some effort
- A "file-viewer" for handouts.

I was thinking it might be good this way:
There is one chat window to start with, IRC-style, but when a student wants to see what a teacher has said, he clicks on the teacher, then a button, and it makes two windows: one for everything said and one for the teacher. That way, if there is more than one teacher, he can see what each individual one says.
Also, for the chalkboard, stamps (such as arrows) would be cool. IMHO, you probably should not start using a jabber server or an IRC server for a few reasons:
* You are going to need a few (lot) of features non-existant in both.
* If you start using jabber/IRC server source, it won't be in python.
* Aren't you using some form of XML? (are you going to use XML for chat too?)

The chalkboard should be stored as an image IMO, and the text in the chat windows should just be text. But, I'm just a on-looker, so use XML if you want to :)

[Jhonas]

Originally posted by Bradmont
we could do a java client, and cover everybody that way.

What about Python?

Or are you talking about just the server would be in Py? That WOULD work, as I created a client/server app where the client was in VB (I know, I know. Don't rub it in, please) and the server was in perl. The server did all of the processes, while the client just sent what you typed and commands.

[l01yuk]

I think that the chat should be IRC based since people know that already and the less that people have to learn to use a new tool the better. Also, the files need to be in a format that is useful, i.e. that can be opened in just about any WP and also that are not bloated so that people with 56k modems can download them without too much trouble. We could always build file compression in as well for file transfers.

Also, there really does need to be some kind of flagging when people want to talk and a way for the teacher to let them/stop them or it could get really messy, especially on the board with people writing on-top of one another because of time-lag problems.

The clients could be [as suggested] dumb terminals and the python server does all the work. The clients could be written in almost anything that way, perl is portable to windows and has gtk modules so that would be a possibility perhaps. Java though isn't really portable to windows any more, not long term anyway because I think that Redmond are doing away with it and using c# instead.

[kmj]

Does anyone here use mac? I don't think I can really develop for mac, since I don't have one. If any mac user wants take an active part in ensuring the programs run on mac, that's fine with me... :)

I don't think the GUI toolkit is the biggest deal, anyway.. theoretically, we could make it so you could just pull one frontend out and stick another in.. That would be nifty.

[kmj]

Originally posted by vomjom

Nope. In fact, it might be better single-threaded.


Do you mean using asyncore? Or just straight single threaded and minimize the time handling client requests? If you have experience in this area, writing servers for multiple simultaneous clients, please expound.. (and example code would be cool!)


Well, to be honest, you aren't going to be able to do much with Qt Designer or glade for this program, because the only hard part of the GUI is making the chalkboard (which isn't that difficult). The only features I can think of for one right now are: Typing-mode. Chalk mode. Eraser.
The GUI certainly isn't the hard part, and the choice between QT and GTK+ is an unimportant one (you can always change later with minimal effort).
Either way, both work in windows.

No doubt. The interface is not the thing to get hung up on


"Easiest language to learn you've seen" is a bit far-fetched, isn't it? Python is a good choice, though :)

well, it's the easiest that I'd consider using :)


I was thinking it might be good this way:
There is one chat window to start with, IRC-style, but when a student wants to see what a teacher has said, he clicks on the teacher, then a button, and it makes two windows: one for everything said and one for the teacher. That way, if there is more than one teacher, he can see what each individual one says.
Also, for the chalkboard, stamps (such as arrows) would be cool.

This is an interesting Idea... I hadn't even thought of handling multiple teachers. That makes sense. Re: stamps, you mean like sprites? yeah. They would definitely be good to have.


IMHO, you probably should not start using a jabber server or an IRC server for a few reasons:
* You are going to need a few (lot) of features non-existant in both.
* If you start using jabber/IRC server source, it won't be in python.
* Aren't you using some form of XML? (are you going to use XML for chat too?)


Well, the twisted framework that Bradmont posted does have a python IRC server; and while we would be making potentially lots of extensions (after all, this is a new program), alot of the basic stuff is in IRC... So I don't think we should rule out building on IRC, since it would potentially give us a real head start..


The chalkboard should be stored as an image IMO, and the text in the chat windows should just be text. But, I'm just a on-looker, so use XML if you want to :)

I agree that the chalkboard would be an image, some simple image format.. I don't think the chat should be XML.. not sure that's necessary.. the only things I see going on in there are syntax hilighting and url-linking, but those are interface things that are apparent from the content.



Also, there really does need to be some kind of flagging when people want to talk and a way for the teacher to let them/stop them or it could get really messy, especially on the board with people writing on-top of one another because of time-lag problems.


Yeah, the way I see it, when a student wants to speak, he "raises his hand" illuminating an icon on the teacher's client. The teacher selects a student, allowing him voice privileges until he deselects the student. This could be turned off for smaller classrooms.

[Bradmont]

kmj: I think he means we should use non-blocking I/O (I'm not sure if that's what asyncore is, I've never looked at it...)

[inkedmn]

let's not forget that Jython (http://www.jython.com) is readily available and would integrate very easily (AND let us utilize the swing libraries) :)

thoughts?

[Bradmont]

Jython is kind of weird to use... I've played with it a bit, not much though. It's also non-Free, which is bad.

[kmj]

[disclaimer: I'm drunk]

Brad: I've read the python module documentation for asyncore (that's the name of the module), and unfortunately, I'm still not sure what it is exactly, except that it's a way to handle asynchronous socket communications in a single thread... I guess I don't see the connection between non-blocking and single threaded... I mean, I guess you could handle all the client connections in one "traditional" single threaded application, but you'd have to be rather fast about it..

I checked out the Twisted framework, and I think I'm a optimistic about being able to use that as the basis for our server, and possibly our client... I'll have to delve deeper into it tomorrow, when I'm sober.

[vomjom]

Originally posted by kmj
[disclaimer: I'm drunk]

Brad: I've read the python module documentation for asyncore (that's the name of the module), and unfortunately, I'm still not sure what it is exactly, except that it's a way to handle asynchronous socket communications in a single thread... I guess I don't see the connection between non-blocking and single threaded... I mean, I guess you could handle all the client connections in one "traditional" single threaded application, but you'd have to be rather fast about it..

Actually, the reason I said single-threaded might be better is because it's usually faster. The only reason you would _ever_ want a multi-threaded socket program is if it is largely I/O bound (examples are an HTTP server or FTP server).
Certainly you would not want to create a new thread in the client, and I doubt you would want it in the server.

Think of it this way:
Say you have 100 students, would you have a thread for each of them? You have to send the same data to pretty much all of them anyway, so threads are entirely out of the question IMO.

Async I/O is actually quite fast and very unprocessor-intensive. And yes, I have done it before, when I helped make a MUD.

BTW, you guys know the rules for daemons right?
1. fork()
2. setsid()
3. fork()
4. chdir("/")
5. umask(0)
6. close stdin stdout stderr
7. maybe open a logfile as stdout and stderr, /dev/null as stdin

You can ignore the first fork() if you don't setsid()

[kmj]

vomjom: okay; that makes sense.

[l01yuk]

That only really goes for a deamon that is started with a controlling shell. I think that something like this would be better started from inetd since it would only be used occassionally compared to a web server that is always on. If we do this then such a procedure is not needed to put the job into the background because it is handled by inetd.

Also, you should always setsid really or the process can regain a controlling tty since it never becomes a session leader in its own right otherwise.

[Strike]

Actually, python-gd could make a chalkboard thing nice and simple too :)

[Strike]

Oh, and I'd be down for playing around with this too

[darelf]

Just my thoughts:

I agree, single-threaded is best with this type of application.

I'm not sure twisted is worth the time spent.

I hate Java. And swing is slower than my grandma if you broke both her legs.

IRC-type code is fine... but the original idea was to re-use some IRC code already created. Maybe we can rip out the IRC part of Twisted, but I'm not optimistic about it.

I think you're worrying too much about the socket i/o. It is not complex, and it is very fast. The toughest part of that whole equation is *what* to send over the socket. (i.e. what kind of messaging protocol will we use? IRC? some IM variant? a protocol of our own devising?)

And the chalk-board. That will also pose the most problems in terms of how to implement and make sure updates work seamlessly in a networked situation with lag.

EDIT: Also, we are at four pages now... not sure if that means anything.... Should we have a different medium for discussing this? I think we are all agreed to do the project, maybe we should have a mailing list?

[l01yuk]

maybe we should have a mailing list?

I think this is a good idea.


I think that IRC is a good choice for messaging as I have said before, however, I do have concerns about it regarding inattention to the teacher owing to the ability to /query people. On the other hand it can be useful to talk to other class members during lessons to clarify points quickly and without addressing the teacher. It could be worth us creating our own protocol and having 2 message windows (as has been suggested) with no ability to spawn new windows and chat privately. If chat not directed at the teacher are open for all to see it should stay more on-topic. The teacher can actively moderate it this way as well.

This has pretty much all been said before, I suppose I am just adding my £0.01 worth to it.

I think we are going to have to create our own protocol generally for this since we need to differentiate between messaging, drawing updates for the whiteboard, text updates for the classroom materials and so on. I think the whiteboard will take the most thinking about since we will have to deal with it in an differences manner, sending and receiving drawing controls depending on whether the teacher clicked the user's 'raised-hand' or not. It wouldn't really be any good to set the draw flag for a user, draw on the board and send as a picture file since it would cause lag on slow connections that could be unbearable, especially if the board becomes busy.

Also, I think that when the user is allowed to write on the board a new window with a large board should pop-up for them to draw on, a smaller 'view-only' window being present in the corner otherwise.

[kmj]

You're right; this thread is getting rather long.

Since I planned on turning to sourceforge eventually, and sourceforge does have a mailing list feature for projects, we might as well go ahead and set up a project on sourceforge..

I'll go read the docs and request a new project..

Is there anyone here that does not have a sourceforge account; or has one under a different name?

Oh, one last thing... any good ideas for the name of the project? :)

[darelf]

Originally posted by kmj


Is there anyone here that does not have a sourceforge account; or has one under a different name?

can't remember... it will be *darelf* if I can manage it.



Oh, one last thing... any good ideas for the name of the project? :)

Seminar?
pyRC? (sort of a play on IRC.... meh)

[kmj]

I went ahead and submitted a project request to sourceforge, I'll let y'all know if it's accepted.

W/ regards to IRC: I don't see what's wrong with piggybacking ontop of it.. We'd end up with our own protocol in the end, clearly, but it seems like we really want all of the (main) features of IRC, perhaps with some minor modifications. We could still have two (or more) message windows using just the irc protocol, couldn't we? That's really just an interface thing.

Re: Twisted; well, it does make writing a server quite easy, as far as I can tell, even if we don't need all the functionality.. but the thing is, twisted allows us to support a multitude of protocols with a single application. So it could make our job much easier. I still haven't really seen evidence to solidify a decision either way.

I hadn't even thought of allowing students to draw on the chalk-board, but that's definitely a feature we'd want. I think the easiest way to handle the chalkboard would be to just send it back and forth as a png file. The drawer can make his drawing and click a send button to send it. That seems the easiest way to minimize traffic.

Fileviewer: While plaintext would keep it simple, It really seems like it would benefit from being able to display images as well. I.e. embedded images in the file, as in a .doc or .pdf file. That's why xml seems like a simple solution. Perhaps we can plan to make this extensible, i.e. providing plugins for different file types. We can start with just plain-text and move on from there, later.


Does everyone agree that the protocol is really the essence of the application? After that, I guess it can be broken down into the following categories:

-server
-- we know it's single threaded...
-client:
--networking
--chat (if not IRC, then IRC-like)
--fileviewer (format still undecided)
--chalkboard (probably GD)

[stuka]

An addition to the chalkboard issue: if students are able to post to it, we should have a 'chalkboard stack' so the teacher can refer back to previous drawings (actually this could be good in any case...).

[kmj]

I definitely want to do that. Should have put that down. Kind of a drop-downlist of all the previous drawings.. or perhaps a seperate tab with a list.. and it'd be a good idea to be able to save the drawings locally.

Here's a question:
Should the server log an entire session (all text and images), so that late-entering students don't miss anything? It's a bit of requirement for the server, but it seems reasonable, given the program's goal. A similar thing was proposed to deal with the lag issue; or incase someone gets dropped. This has the added benefit of allowing anyone to recover previous sessions with ease, which seems like a good feature.

[stuka]

I'd definitely say that's a must - in that online class I took, all of the class chat sessions were archived, and it was useful, as I could go in and check them later (I had another class on the chosen day) and pick up any good info available. If drawings are available and used, we need to keep them for reference purposes.

[kmj]

Okay, we have a sourceforge project now.

http://sourceforge.net/projects/classroom

The project name is simply "classroom".

l01yuk and Jhonas: I need a Sourceforge ID before I can add you. I've added everyone else on the list. If I've missed anyone, or anyone else would like to be added, please let me know.

I'll get to reading the docs so I can be a decent project admin and get that mailing list set up.

[Bradmont]

I'm not sure I agree about sending the image back and forth as a png. I mean, what if you want to draw on someone elses chalkboard, and what if someone else draws on it at the same time? That could be rather difficult to handle with just sending the whole thing out (and not to mention it would be pretty bandwidth intensive.)

[l01yuk]

kmj

I didn't have a sourceforge id so I have registered but I need to log in and collect it which will have to wait until tomorrow since it seems my browser won't follow some secure links :( . I'll let you know as soon as I can, as well as getting a new browser as soon as I can, *$&%" browsers!

[kmj]

okay.

Braqdmont: So you think we should send blackboard info bits at a time, kind of like just a list of pixels to XOR?

[kmj]

When you guys get a chance ... (everyone except from strike & blarg, who already did) .. can you head over to the [url=http://sf.net/projects/class[project page[/url] (you must be logged in to sf), and read the couple of threads I've posted there. Then go ahead and subscribe to the mailing list... Thanks.

[Strike]

Actually, if you use SVG, you could just send diffs to the .svg (since it's XML). Then draw on a back-buffer and blit to the screen.

[l01yuk]

kmj:

I have an acc on sf now - sol01yuk - apparently someone already had l01yuk ???

[kmj]

wierd. :)

Strike, I'll look into SVG.

We have a chatroom (#classroom) on irc.openprojects.net, now too.

[l01yuk]

As far as IRC goes it looks like most of you are in the US, whereas I'm in the UK. This probably means that unless any discussions take place during the early part of the day over there I will miss them owing to the fact that I am getting some kip. Just out of interest, are any other people involved from a TZ closer to GMT? Anyway, becuase of this can you make sure that anything important decided on IRC is relayed through the mailing list.

[kmj]

Is kip the british word for "play"? (as in gettin' some) ... or sleep? :) just curious.

l01yuk: I just added you to the sf project. Sorry I didn't do that yesterday.

That's the one problem I have with IRC, it's not "permanent", or less so than email or a bbs. (unless you log, I guess), but it's still good to have somewhere to chat about it if/when we need to.

Most of the guys are in western us, so that's even worse. :)

[l01yuk]

kip - sleep.
I think all the words for playing have already been nicked by you yanks. ;)

[inkedmn]

maybe we should throw together a quick phpBB dedicated to this project somewhere (maybe inkedmn.net), because the forums on sf.net are just ugly (IMHO) :)

[kmj]

inkedmn: we'll probably use the mailing list most extensively, and leave the forums for special case things... like compiling lists or something. That's the way I see it. I don't think we need to start a whole new bbs just for this project. The sf ones should server their purpose, even if they are ugly. :) (my opinion, obviously)

[Bradmont]

I hate when people assume I'm from the USA. :grr:

[Strike]

Originally posted by Bradmont
I hate when people assume I'm from the USA. :grr:
Uh, wtf?

[l01yuk]

I hate when people assume I'm from the USA.
Considering I was replying to kmj who lists his location as NY...


Where are you from anyway Bradmont? Then we won't have to guess :)

[stuka]

Bradmont's from western Canada - near Vancouver IIRC.

[darelf]

Originally posted by Stuka
Bradmont's from western Canada - near Vancouver IIRC.

Isn't that a suburb of the US? (j/k)

[stuka]

/me ducks to avoid the Canadian wrath

[kmj]

Originally posted by Bradmont
I hate when people assume I'm from the USA. :grr:

Stupid whiny americans. :D





I'm closing this thread since we have the mailing list set up, and everyone seems to be signed up.

Jhonas (or anyone else), if you're still interested in joining up, get a sf account and post in the Developers forum at http://sf.net/projects/classroom .