Work History

Innsbruck

Three parallel tracks were done before the Innsbruck meeting:
- Actors, written to test against existing system
- Requirements, written to test against existing system
- basic Block Layer in the Architecture
Existing Code was reviewed
1. Round table discussion of the issues
2. Code-diving session
3. Collection of all the issues into the Reimplement or not? Document.
4. Conclusion taken that only Option 3 is reasonable. Redesign, rebuild.
5. Document reviewed and signed off on by the software evaluation team.
In the first design meeting, the Actors were re-worked, without reference to the original file, as Actors2.
Actors2 was fed into a design effort of roles/tasks, which was documented as aa RESTful API in URL Space.
Then, the use-cases in both Actors1 and Actors2 were tested against the URL Space API design.
- In parallel, both versions of Actors were merged into the one file Actors.
- Security discussion about JavaScript and how the Application resource is managed.
- communications discussion was vibrant around choice of datagram or queue model.
Finally, the Data Model was constructed
- earlier discussion was towards SQL v. flat files
- discussion agreed on use of SQL database, with some leaning towards PostGRES.
Discussion on technologies covered:
- Java for the Business Logic Engine, codenamed Shack,
- Tomcat as the container for the BLE/Shack,
- Apache mod_proxy as lightweight filter,
- PHP for the frontend, which should be fairly lightweight and transparent,
- Javascript for the majority of the client-side activity.
Basic protocol elements scratched out for new SigningServerCommsModule.
Work done on this wiki/environment
- new version installed
- some stuff done with SSL client certificate authentication over wildcards
- lots of blah blah in preparation for mass hacking

Essen

See Minutes20091216EssenSoftwareMiniTOP for a brief review of Birdshack within a wider meeting. Topics:
- ABC for Wolfgang.
- Software Repository.
- Review of Birdshack
- Root Ceremony