I’m collecting notes here to get feedback on them until I get access to the infotrace wiki, at which point I’ll probably just start posting over there instead.
Architecture
It’s pretty simple. infotrace.citizenlab.org (DNS isn’t working yet) is running django and a postgreql database; the database could easily be split off to another machine if load requires it. Queries will be generated by researchers accessing the web interface, and will be sent off to the Planet-Lab “cloud”. Most of the dirty work there will be done by the various Planet-Lab API’s I’m still trying to get my head around.
User Roles
This should mostly be taken care of with django’s admin module, but I figured it was important to write up as well.
- Administrator: can create leads and researchers, can delete either, can create and set limits on leads and researchers
- Lead researcher (a.k.a. lead): can create / delete researchers up to a certain number, can run queries
- Researcher: can run queries (subject to limits set by researcher)
Requests
Requests which go out to the Planet-Lab infrastructure can take a number of forms:
- one off requests with a single source and single destination
- timed monitoring requests which repeat on an interval, from a single source to a single destination
- variations on multiple sources, multiple destinations, and monitoring or not
- other types which I’m not thinking of?
Visualization of Output
- kml file (google maps, google earth)
- csv file
- ??
hypatia dot ca 