Original author: v...@aarontitus.net (January 14, 2013 23:11:19)
There is no "One App to Rule them All," and this is no exception. Ideally, this app will show the disaster recovery community how to truly coordinate and communicate. Ideally, the app should include a robust API to share information with other applications.
The API needs to accommodate these use cases:
Accept Canvassing/ Damage Assessment information from members of the public using a Facebook app
Accept Canvassing/ Damage Assessment information from members of the public using a third party smart phone app, like voluntari.ly
Share public information with clones, like Crisis Cleanup Australia. I suggest this is best accomplished by launching another service that communicates with all clones by default.
Share the XML Incident Definition and/or Incident Definition attributes with authorized users.
Share public mapping information with authorized users
Accept additional map information/ layers from other sites.
As a first step, the app should be designed communicate with other copies of itself by default.Organizations may do their own implementations, as long as it communicates non-identifying information with a central server… Everybody talks with everybody else.
How should the network topology be designed? Should there be a central server that coordinates? Should it be a P2P network topology? I'm open to ideas; but at the least clones of this project should communicate with one another by default.
Original author: v...@aarontitus.net (January 14, 2013 23:11:19)
There is no "One App to Rule them All," and this is no exception. Ideally, this app will show the disaster recovery community how to truly coordinate and communicate. Ideally, the app should include a robust API to share information with other applications.
The API needs to accommodate these use cases:
As a first step, the app should be designed communicate with other copies of itself by default.Organizations may do their own implementations, as long as it communicates non-identifying information with a central server… Everybody talks with everybody else.
How should the network topology be designed? Should there be a central server that coordinates? Should it be a P2P network topology? I'm open to ideas; but at the least clones of this project should communicate with one another by default.
Original issue: http://code.google.com/p/sandy-disaster-recovery/issues/detail?id=156