Yesterday, as part of XOCamp, Caroline Meeks pressed me a bit to talk about my vision of the XS going forward. It is a somewhat hazy space, as it's unclear whether I'll be able to work fulltime on this after XS-0.6.
Now, even when you feel really certain about your future plans, a bus could roll you over. Or your convertible could leave the road and crash on the rocks in the sea. So what's the XS plan then? With 0.5.1 much of the infrastructure work is done, including network services. With 0.6 that work should be complete, even if it'll be lacking some nice-to-haves. Pat-on-the-shoulder, job well done. The next stage -- if *I* get a chance to get it done -- is all about focus on server-based education tools. First stop, Moodle. Right now there is a barely usable moodle that auto-installs. I've written 2 plans for it -- one focused on the technical and more "mechanical" issues, parts of it are already done, but many remain to do: http://wiki.laptop.org/go/XS_Moodle_plan the second plan is more focused on making Moodle useful with primary schoolers. Currently, moodle is great for text-centric interactions, forums, wikis, reading content. But children 6 to 9 years are not text centric yet. Surprisingly, it's not so hard to address that - along with a host of other things to lower barriers of entry for classroom use - see http://wiki.laptop.org/go/XS_Moodle_design It's probably about 8 months of work to get through all that. So a year out, my crystal ball gets hazy -- in the fog, I can make out the outline of some further plans, such - merging edublog patches, make the moodle-based blog able to publish to internet-based blogging sites - such as blogger.com - add a wikipedia-slice to the server - while the laptops do have a "wikislice", the server can host a much thicker slice, and perhaps have it editable too - complementary tools: Mahara, Mediawiki - of course, better tools to manage the deployment... - rebase on Fedora 11 or 12 (skip F10 as it's missing bits we need) - rebase Moodle work on Moodle 2.0 - which brings a nice API to deal with repositories, unlocking a lot of content-repository options - replace squid with rproxy and hashcache - use btrfs as soon as usably stable, wrap yum/rpm actions in "snapshot-try-or-rollback" scheme... there you go. Now I can go back to living life dangerously without feeling guilty :-) Note note note note: this is pretty much *my* plan, my perception of the most reasonable tradeoffs between the competing/conflicting feature requests and the physical and resource constraints. Anyone prepared to spend the 1% inspiration + 99% perspiration can refocus this plan on areas that I might be ignoring... by getting it done. In other words, the above is all hot air, and hot air doesn't count. Working code does ;-) cheers, m -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
