Difference between revisions of "STP Deployment Framework Requirements"
Latest revision as of 08:49, 1 May 2006
Growing and Vetting the Requirements
New requirements from committers should be added directly to the page with a reference to the author of the requirement and the text "[Proposed]". Each proposal should be vetted through the IRC meetings on Wednesday before it is changed from [Proposed] to [Accepted on date].
- Should be able to contact a remote, running runtime instance. This means that you can do your deploy from your development host to a test/preprod host somewhere else. [Proposed] (Oisin)
- Should support the development of new connector instances to new runtimes. Now, just a clarification here: when I use the term 'support' then I do not mean 'allow' :) With 'allow' you can get it done by writing reams of code, with 'support' the framework makes it easy for you to focus on just the code you need to talk to your chosen runtime (note that this could be reams too, but you are at least writing in your area of expertise). [Proposed] (Oisin)
- Should not define any extra creation paths for a user defining a new server in their workspace beyond providing extensions to existing frameworks. That is, no new framework code for creation paths. There are already frameworks in WTP/DTP for this purpose, and STP should leverage these directly. [Proposed] Melder
- Should not define any new views for the monitoring of running applications on runtimes. There are already existing views in WTP/DTP for this purpose, and STP should leverage these directly. Creating new views for monitor servers will confuse the user experience by exposing multiple ways to monitor different kinds of servers, based on what the developers thought; not based on what the user expects. [Proposed] Melder
- Should avoid defining any new concepts that are already satisfied by existing frameworks. The community should review the WTP Project Facets and understand how to integrate with this framework [Proposed] Melder
- Should avoid being overly complex, both for users and for developers extending any STP-defined framework. [Proposed] Melder