At 9:56 PM +0000 12/18/10, Bjartur Thorlacius wrote: >On Fri, 17 Dec 2010 10:42:52 -0000, Diogo Resende <[email protected]> >wrote: >> >>- Does the OS need to know how to fetch this information? >Yes, the purpose of an OS is to abstract and multiplex hardware. >Does a web app need to know how to fetch this information? > >>- Is a browser plugin really a better idea? Which browser/version? Then >>how is the page going to fetch that? How secure is that? Can't another >>page do it? This reminds me the use of <embed> which I personally hate. >I agree that a browser plugin would the wrong approach, but I argue that a web >page would be as well. I can't imagine a scenario where I'm developing >software support for a Bluetooth weather station and I figure: "Heck, I should >put a web browser between the Bluetooth stack and the weather station >abstraction."
I've been creating educational science applications which let users collect, analyze and share data from probes and sensors. It is a huge plus to be able to deliver this type of application and educational learning experience in a browser. For quite a while we've been deploying these activities/applications using Java Web Start. The code is open source and works with probeware interfaces from five different commercial vendors. However there are many problems deploying Java Web Start applications in schools and I'd rather deploy to an application running directly in the browser. In addition much of our current research is in exploring the learning benefits associated with collaboration -- this is much easier to prototype and scale-up using web technologies. Recently I've been able to create a demonstration in a browser that graphs data from a Vernier GoMotion USB probe (measuresdistance using and ultrasonic ranging device). If you have a Vernier GoMotion probe plugged in you can just open this page: http://jnlp.dev.concord.org/goio-motion-graph.html and be graphing data from it within 30s. If you don't have this probe here's a screencast showing it working: http://screencast.com/t/7mmYpknbgoSz The current implementation uses a Java applet which also includes os and arch-specific native libraries (totalling about 500k). Almost all probeware requires a user to install a driver ... however the Vernier GoIO series of probeware interfaces do *not* require installation of a kernel driver because the devices register themselves as USB HID devices. the result is that opening and using the Motion Grapher page does *not* require a user to install a driver into the OS -- whichmeans that this can normally be run in a school without requiring a user to authenticate as an administrator. This is ahuge plus. Recently I've had interest in extending this system to support Aurduino devices. I'm also interested in having access to BlueTooth sensors so I could create a similar experience for systems like IOS and Android which often don't have a USB interface. The <device> spec is hardly a spec at all ... really just a placeholder for conversations like this and I haven't yetthought much about how it could be built to better support these goals. But I think I can make a powerful case that being able to create web-applications that can integrate easily with I/O devices that extend your senses is a wonderful area for innovation. references: https://github.com/stepheneb/lightweight-sensor-graphs https://github.com/concord-consortium/goio_sdk http://code.google.com/p/org-concord-sensor/ https://confluence.concord.org/display/CSP/Intro+to+SAIL-OTrunk
