Meeting 2013 06 18 Agenda and Notes Roadmap Planning

Agenda and Planning Notes

Milestones? Important key things to do?

I) Formalize and fully document Client API for release 1.0

• This will be a master API that will be used to base all language APIs off of. It should have base versions of function calls that will be clear, understandable, and regular for as many languages as possible.
• One part of this will be deciding what our target platforms are, or some set of platforms that we at least want to keep in mind when we consider adding new types (i.e., Arduino Uno? Flash?).
  • We should create comprehensive list and identify which ones we want to support for release 1.0 and which ones should be considered for future releases.

II) Formalize and fully document Server/Client Communication

• Identify if there are any additional features we want to add to the communication protocol for release 1.0
• Consider if we want to add any attributes to communication thinking about extendability for future

III) Ensure that all supported libraries match the previous two specs. Probably also create a test suite to test communication protocols as well as client APIs.

IV) Base types: how can we talk about

• reserved types (Vec2, Vec3, CvBlob, ?)
• creating your own "known" type (e.g. I make apps that send "MyDopeType")
• one-off types

V) High performance: what's the barrier to sending binary data or other high-performance stuff?

VI) Add federation

• What is meant by this?
  • http://en.wikipedia.org/wiki/Federation_%28information_technology%29 "In networking systems, to be federated means users are able to send messages from one network to the other."

VII) Formalize and fully document Server/Server Communication

• Do we have server/server communication? What do you have in mind here?

VIII) Refactor the server to some optimized language: Go, or C++, or Erlang, or Python

• "The idea generally is to make a standalone server as fast as possible."
• I think this should be a future release and not version 1.0. Definitely up for discussion (JT)

Other major milestones to discuss:

• Include an API for the Server, so it can be used directly in projects (this paired with Federation would allow for p2p comm.)

• Include support for generic p2p communication bootstrapped by Spacebrew somehow. Examples where this can be useful is with setting up WebRTC communication, or using UDP broadcast.

• Perhaps this is simply us making a few examples where we use Spacebrew to do this bootstrapping, then people can use those as "recipes" to migrate communication from Spacebrew to a more optimized comm. for their particular project. As experienced in our other events, we want the switch between communication systems to be as turn-key as possible.
• On a side note: I believe the WebRTC consortium has a C++ library so we could ostensibly use WebRTC in C++ apps as well as the browser (and Python, Perl, etc. if we put together the hooks for the C++ library).

Notes from Meeting

Spacebrew Client Library API

• We will develop guidelines for the method names, parameter, and core functionality.
• For release 1.0 we will want to bring all libraries into the fold that are in the group.

Data Types and Target Platforms

• Data types: what are the data types we want to support
  • How will our target platforms drive the data types that we want to support?
  • Should the Arduino be our base client that we use to base our (Decided: Yes)
• Standard data types
  • We don’t want to lose the range
  • Agreed to add number that aligns to Arduino Uno integer
  • Considering adding a float data type as core data type *(Consideration: do we use the imperfect representation of a float as a decimal in the JSON, or parse the float to/from a raw HEX value to preserve the value fully intact but make it more opaque to humans. One option is to have a more complex object that wraps both and the library can choose which to use. Same consideration comes up if we want to support double) *(see http://www.cplusplus.com/reference/cstdio/printf/ with specifier 'a')
• What does it mean to be a standard/supported data types
  • These types will be integrated into the libraries *(I'm imagining library tiers, where tier 1 supports all "base" types, and tier 2 supports all "extended" types.)
• High level data types
  • What high level types could also be helpful to have
  • Do we want to have a 0 to 1 or a 1 to -1 range
  • Vec2 is another type that could be useful to have
  • Let’s talk on the wiki about what additional types we want
  • Create a spreadsheet that maps out the target platforms and what data types they support *(Done: https://docs.google.com/spreadsheet/ccc?key=0Au1jvUiMMszidEk1bW1mOTBOUGRMRkhTemJobzl1MUE&usp=sharing)
• Community data types
  • Create ways for people to create data types and share with the community
  • Think about ways to enable people to share a data type
  • Integrate the ability to make a type discoverable into the admin tool
  • Enable people to create a config that is used by the standard libraries to be able to handle the type

Service, Toolkit or App

• Is spacebrew a service, a server or a app?
  • It functions like a server in that you don’t ever have to download spacebrew, you can just join it.
  • How can spacebrew be more like flickr, in that you never thought about how can I reproduce flickr.
  • How can people sign up for spacebrew?
  • Where does it make sense to talk about like a service, app, toolkit, platform, etc
• Adding spacebrew to high schools, colleges to different locations as a local service like bonjour

Spacebrew as a Methodology

• Think of spacebrew as a methodology for creating interactive spaces or internet of things.
• Make so that people can create a different version of the server
  • These versions could be interchangeable with each other.
  • Each offering different feature/performance/etc but able to connect to same clients/servers
• Enable people to recreate any part (server or client) using a different language or platform.
• Spacebrew as protocols and relationships, rather than a specific technology implementation.

Create / Explore new versions of Admin

• Create new versions of the admin, that can load and save route configuration.
• Interesting how remapping routes can transform the experience/space.
• One of the biggest issues with spacebrew is how arduino and processing talk to each other.

Next Steps

• Set-up bi-weekly meeting to work on Spacebrew stuff
• Thing to do at next meeting:
  • Agree on high-level timeline for release 1.0
  • Create workgroups and assign tasks / responsibilities