The EPGY clients came back today with a neat idea; a Flash 'gatekeeper' for Java applets. One of the recurring problems is ensurng that the Java applet has landed in the browser and has authenticated back to the host for the super secret assessment conversation that has to follow. They have a little stub which handles the timing of that conversation. This will be useful. I like how it all comes round.
The EPGY folks are doing amazing analysis of spoken language elements at the phoneme level; their applet does some of the analysis and then hands back an abbreviated form for server side analysis. @ the end the big iron on the server hands back an automated assessment of the pronunciation. wow.
Design for testing
We've an ongoing high-stakes testing which has never been well funded ( on the service side ) but continues to have high campus expectations. It's sorta typical how $$$ will roll in to fill a lab with equipment but no funding is around for building an ongoing software service support layer. It looks like Stanford is finally stepping up to the challenge of developing a solution. The team will be a mix of our own staff and outside consultants from Texas.
I'm trying to weave into the emerging design a set of capabilities which promote end-to-end testing of the necessary plumbing. I think the test administrators should be able to check out how the service is behaving at any time. Hopefully before turning the controlled test over to the students. My goal is to make it easier for the lab machines to co-ordinate mass downloads and updates through Sakai.
One of the hassles @ stanford is that the our network is essentially completely open. Only in th last couple of years have private routings for services such as Coursework been an option. One of the results has been that high-stakes testing network traffic can collide with some oddball migration of data from a linear accelerator, or a DNA dataset. Try explaining that to a part-time instructor of Hangul. Stanford is starting to separate traffic but it will be important to do a 'look ahead' from the labs.
I'm curious as to why no-one on the Sakai dev list has sensibly responded to my questions about bulk data delivery w/Sakai - whether the CHS architecture and implementation were up to the task of delivering and accepting a large number of discrete files w/in a few seconds. There was a short discussion about Streaming and / or having Apache handle the files ( we're doing that now ), but those responses missed the point about using Sakai ACLs for content access. Lydia opines that no one knows. I think that's true. I think the legacy code will barf all over the server room floor.
After experiments facilitated by the ad-hoc testing design we may have to do as we are with our PHPBB / Apache .ht* file integration, and express Sakai authorizations in a remote mechanism via web services and REMCTL calls.
I think I got lift head this weekend past. I was skiing at a ferocious rate, and getting back to the lift every few minutes. The lifts can haul you up a couple thousand feet at a time. The GPS I was carrying was showing ridiculous amounts of total ascent. Headaches were the result. Oh but the skiing was great.