Differences between revisions 6 and 8 (spanning 2 versions)
Revision 6 as of 2002-06-17 15:11:00
Size: 5077
Editor: challenge
Comment:
Revision 8 as of 2002-06-20 14:18:05
Size: 5550
Editor: scf5-fe0-1
Comment:
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
 * It should have the notion of owners and maintainers (tech contact) of nodes.
 * Group data should maybe include lots of things (name, lat/long boundries, url, contact person, list, report problem, cities (??), countries(?)).
 * Should have the notion of roles (eg. whois). Nodes don't have contact info they point to a person (so when you update your contact info, any nodes that you are associated with are updated at the same time).
Line 33: Line 36:
 * It should be capable of protecting the users privacy. EvilBunny from SyndneyWireless has some interesting thoughts on the subject. See his [http://www.nodedb.com/ NodeDB] project for how he implements it.  * It should be capable of protecting the users privacy. EvilBunny from [http://www.sydneywireless.com SydneyWireless] has some interesting thoughts on the subject. See his [http://www.nodedb.com/ NodeDB] project for how he implements it.

There are lots of ideas how and what our MappingSoftware (currently the WnDb) should do. Here's the beginnings of a list of requirements for a possible rewrite by SethShikora.

The mapping software is the technical heart of the community. It is what shows us what we've accomplished and allows us to set and meet goals. By measuring usage statistics it is also what allows node owners to feel the PrideOfOwnership and understand their contribution to the network. Due to the volunteer nature of a CommunityNetwork it should be as self maintaining as possible and as decentralized as possible.

Some of these goals are obviously ones for futher down the road, but hopefully thinking about them early on will allow us the better achieve our end goals. For a list of current wishes for the WnDb software please see the WnDbDevel page. -- AdamShand

Core Features

  • It should be able to display maps for single nodes or geographic regions.
  • It should be able to differentiate between different NodeTypes and their status.

  • It should be simple to install and maintain and have as few external dependancies as possible. This is because other CommunityWireless groups will need to be able to set it up for themselves.

  • Should be an API (HTTP, XML-RPC, SOAP ... whatever) for manipulating node data.
  • Any data storage schema (SQL?) should be as generic as possible to allow future ideas to be worked with. The schema should have a notion of users, nodes and usage metrics.
  • It should follow our principle of ZeroMaintenance. This means that where ever possible maintenance tasks should be automated or distributed to the user base.

  • It should be able to draw lines between nodes where connectivity exists and map out the logical network.
  • It should have the notion of owners and maintainers (tech contact) of nodes.
  • Group data should maybe include lots of things (name, lat/long boundries, url, contact person, list, report problem, cities (??), countries(?)).
  • Should have the notion of roles (eg. whois). Nodes don't have contact info they point to a person (so when you update your contact info, any nodes that you are associated with are updated at the same time).
  • [FUTURE] It should be able to make overlaid node data clearly visible over the maps (eg. by making the street level map grey scale and nodes color).
  • It should use a projection (and ideally a data source like MapBlast) which will work world wide. [FUTURE] Ideally it should be able to serve node data with different backends (street data, elevation data, topographical data etc).

  • [FUTURE] Should have the concept of an "area admin", people who can edit any node data in their area (most people should only be able to edit their own data).
  • [FUTURE] It should be able to graph a coverage range of a node. Either based on a simple radio propagation metric (eg. in a city coverage is primarily down streets) or based on feedback (netstumbler data?) from gargoyles and users.

Scaling Features

  • It should require an email address to register a new node. On a regular basis it should require an ack to a nodes existance to keep the node data as fresh as possible.
  • It sould be able to act as an IP management solution to allow node owners and the SpecialOps team to easily track and manage which nodes are supposed to belong to which networks.

  • [FUTURE] It should monitor nodes for usage metrics and availability and be able to present that information when people are searching for or viewing nodes.
  • [FUTURE] It should be able to interact with the CaptivePortal software as both an authentication source and a node information source. See the MetaNet page for some ideas.

  • [FUTURE] It should be able to exchange node data with other instances of the MappingSoftware which is run by other groups (GAWD by the ShmooGroup is a possible data exchange format). This means it should segregate information by group and have notions of authority (so that only one group at a time is authoritive for any given set of data). JasonLuther wrote a good [http://lists.personaltelco.net/pipermail/mapdev/2002q2/000059.html beginning] of an XML interchange format.

  • [FUTURE] A wiki module should be capable of pulling basic node data from the map server so that node data can be displayed in the wiki via the something like [[NodeData(351)]].

  • [FUTURE] It should be able to store all the information about a node as [http://lists.personaltelco.net/pipermail/setup/2002q2/000830.html per request] by David Schargel.

Community Features

  • It should be capable of protecting the users privacy. EvilBunny from [http://www.sydneywireless.com SydneyWireless] has some interesting thoughts on the subject. See his [http://www.nodedb.com/ NodeDB] project for how he implements it.

  • It should encourage friendly competition between cities, neighborhoods and people. This could be down by breakding down usage metrics by node, neighborhood, city and state. Which neighborhood has the most nodes, the most reliable nodes, gets the most hours of usage a month? Which user has used the most nodes, the two nodes farthest apart, spent the most hours online (most hours online excluding their own node?). Which wireless group has the most nodes, the most active nodes, the most interested people, the highest churn, the most hours used etc. To encourage new groups or neighboorhods it could also measure the rate of growth a a metric.


[CategorySoftware]

MapSoftwareDevel (last edited 2007-11-23 18:00:47 by localhost)