Subject: [core] CHTTP/Sleep-Proxy Demo on Sun SPOTs at IETF

From: Vipul Gupta <[email-masked]>
Date: Wed, 24 Mar 2010 09:50:17 -0700

Hi Folks,

   I'm a researcher at Sun Labs, Oracle, and I have prototyped several of the concepts floating around in this group's discussions -- RESTful sensor/actuator services, Compressed HTTP, sleep proxy/gateway --  for the Sun SPOT platform. 

   This experience brought up a number of issues from minor ones like typos in the chttp draft, to larger ones like gateway discovery and the potential benefit of standardizing some small set of URIs for a device -- e.g. /info where one may obtain information on its manufacturer/model/serialNo etc, or /svc where one may obtain a list of available services. I haven't yet gotten around to putting these thoughts down in an email or ID but I'll be at the IETF tomorrow and hope to meet several of you in person. 

   If anyone is interested in seeing/discussing this demo (I'm attending the IETF only on Thu), please email me. Here's additional information on Sun SPOTs and the demo.

   Sun SPOTs (http://www.sunspotworld.com) are small, wireless (802.15.4), battery-powered devices that can be programmed in Java ME using standard tools like NetBeans/Eclipse on any of the major development platforms (Windows, Mac, Linux, Solaris). They have proven to be quite popular with students, researchers and hobbyists, e.g. search for "spaughts" (deliberately spelt this way to avoid confusion with the astronomical phenomenon) on either Flickr or YouTube for a sampling of the wide variety of projects that use these devices.

   The Sun SPOTs come bundled with several demos and one of these is called  SPOTWeb (video available at http://blogs.sun.com/vipul/entry/sun_spots_spotweb_and_sensor) which lets users interact with a network of Sun SPOTs via a browser. Users can monitor sensor readings, deploy new code and even pause/resume installed applications. The original implementation of SPOTWeb isn't RESTful, nor does it deal with sleeping devices. The prototype mentioned above is trying to address these shortcomings.

   The demo shows the ability to GET light and temp readings from a SPOT via a browser or cURL and the ability to turn on/off or change colors on its LEDs using PUTs. When the device sleeps, the gateway can either  satisfy requests from its resource cache (assuming what's available in the cache is fresh enough for the client) or queue them up for later processing. The response to queued requests includes a URL where the client can monitor the request status. Pending requests are processed when the device wakes up next. Interactions between the gateway and the device may use either regular HTTP or CHTTP (as per draft-frank-6lowpan-chopan-00) and are carried over UDP/IPv6/6lowPAN/802.15.4.

regards,

vipul

--
http://research.sun.com/people/mybio.php?c=509

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Mar 2010 21:11:50 -0600

On 3/24/10 10:50 AM, Vipul Gupta wrote:

> the potential benefit of standardizing some small set of URIs for a
> device -- e.g. /info where one may obtain information on its
> manufacturer/model/serialNo etc, or /svc where one may obtain a list
> of available services.

You might look into the well-known URIs spec (soon to be RFC 5785):

http://tools.ietf.org/html/draft-nottingham-site-meta-05

Peter

-- 
Peter Saint-Andre
https://stpeter.im/