As we move Sensorpedia from a limited beta (with a sneak peek) to an open beta, we have an important decision to make. We are currently evaluating multiple authentication options for Sensorpedia. Some of the options we are currently evaluating include:

• OpenID
• Google Friend Connect
• Facebook Connect
• Twitter oAuth

Each of these options has pros and cons. We need to consider both technical issues (ease of implementation, robustness, networking/firewall limitations) and functionality (features, user base, flexibility). Our original plan for Sensorpedia was to simply use OpenID to offload the authentication process by supporting a number of (all?) OpenID providers. That is valuable in and of itself, but we’d still have to develop and maintain all social networking functionality ourselves. That certainly offers a lot of flexibility, but it’s hard to ignore the benefits one gains from leveraging the existing social networking capabilities of APIs from companies like Google, Facebook, and Twitter. Each of these company’s offerings have some real strengths. Google Friend Connect is easy to use and has a wide variety of widgets available. It also doesn’t tie you to a specific social network. Facebook Connect is attractive because of its size (currently 300+ million users!) and you immediately get the benefit of users’ existing social graphs for sharing and managing groups for access control requirements. Twitter is also nice because of its popularity, asymmetrical connections, and because it’s used more for non-personal communication (which probably fits Sensorpedia’s user base better). The situation is further complicated now that Google and Facebook both support OpenID and Facebook even allows you to log in with your GMail credentials.

So which path should we take? We need a solution that we can implement quickly and also gives our users the greatest set of features for sharing information, managing their social graph, and supporting data mashups. We also want to keep in mind the desire to open source the Sensorpedia software and make it available to run within an enterprise and on secure networks. (Think Wikipedia / Intellipedia.) Would the social networking functionality provided by Google, Facebook, or Twitter have to be reimplemented anyway for such scenarios? These are all issues that we are discussing internally on the Sensorpedia team. We’d love to get your input as well. Please share your thoughts in the comments or get in touch with us on Twitter, Facebook, or LinkedIN.

As we move forward in this area, we’ll begin consolidating our discussion and documentation on the Sensorpedia Developers Wiki.

We value your input and look forward to hearing from you!

It’s August, and the time of interns at Sensorpedia for the summer is coming to an end.  This internship has been a fantastic experience in every possible way, and has helped me develop professionally and technically, to say nothing of the immense and invaluable knowledge of presentation and communication techniques that David has imparted on us.  My sincerest thanks go out to all who have funded us and made this summer possible.

The Sensorpedia Python Library

But let’s talk about Sensorpedia, shall we?  This summer, I’ve focused mainly on the Python library, which while far from really being complete, is now stable and creating feeds.  The Python library provides a “Pythonic” frontend to Sensorpedia, such that registration feeds that are large or that need to be dynamically generated can be generated with a more intuitive and simple programming interface, without having to know anything at all about ATOM or XML.  The library is already being used in several projects and sensor feeds:

• Brandon Zachary’s air quality sensors from the EPA
• Chris Tomkins-Tinch’s iPhone app ("We too are sensors.")
• A feed generated by Chris from Harvard’s Citysense
• ~2000 ICAO weather sensors (updated with current data readings once every hour)
• Several hundred NOAA buoy sensors located offshore of various American coastlines

Feedback from some of these feeds and projects is already helping me decide what the next iteration of the library will look like.  We’re hoping to open source the library and other parts of Sensorpedia such that  people not necessarily associated with the lab can contribute as their interests dictate.  I’m hoping that in the future, regardless of my affiliation with the lab, I’ll be able to continue contributing to this library as a personal project in conjunction with some of my related projects.

As of this writing, the current version of the library is 0.2.3.  You’ll note that we’re nowhere near 1.0 yet, and this is to indicate that the library, as with the rest of Sensorpedia, is still very much in progress.  The interface can (and probably will) change quite a bit as the development cycle renews itself.  That being said, I consider the library to be very stable under normal operation, and would put it forward as a painless way to generate Sensorpedia registration feeds programmatically.

The current version of the library can be found here.

Today I’d like to introduce the first iteration of a python library written to ease the process of generating ATOM feeds for Sensorpedia.  With spylib, no knowledge of XML or ATOM is required to publish a sensor group, though an understanding of the various tags and what Sensorpedia wants to do with each of them is advised. (The definitive source of this information can be found in the Sensorpedia API.)

Creating a sensor registration document is easy as Py:

myfeed = sensor.SpGroup("efa6e019-eca4-4fd6-a37b-c57ad2b1f441")
myfeed.title = "Cool Sensors near Akron, OH"
myfeed.georss_point = [41.090737,-81.496582]
 
mysensor = sensor.SpSensor("efa6e019-eca4-4fd6-a37b-c57ad2bFALLS", title = "Cuyahoga Falls, OH")
mysensor.georss_point = [41.166441,-81.536858]
 
myfeed.addsensor(mysensor)
atomtext = myfeed.toprettyxml()

Some Quick Links:

• Project Home Page
• API Reference

In this blog post, we’ll discuss the rationale behind the library, and provide a tutorial.
(more…)