have the following questions about BES and the various discussions that have recently occurred (including the ESI integration): * Extensibility: * Given that BES has bought into the notion of an extensible activity state diagram, it needs to also normatively define how clients can learn of the extensions that a given BES service supports. Is that something that will be added to the BES specification? Or will the specification point to some other place where notions of extensibility are defined more generically? (Personally, I'd vote for the former approach.) * Is the "base case" for BES now fig.2, which shows states of {new, pending, running, canceled, failed, finished}? * Previously included states, such as Execution-Pending, will presumably be defined in suitable extension profiles? * Assuming that data staging and suspension are now extensions to the base BES spec, will they be defined as such in an appendix of the spec, or as a separate extension profile? * The original BES spec describes a fairly sophisticated data staging design that supports parallelism. Is there any interest in defining a second, simpler data staging extension that avoids the complexity of the parallelism support? * Will the suspension extension be the simple one that is currently presented in sec. 4 as an example? Or do people feel that a more complicated version, such as the ESI one is necessary/important? Can/should we define both? * Given that suspension is no longer in the base design, presumably the createInSuspendedState parameter to CreateActivityFromJSDL should disappear? * RequestActivityStateChange: I believe this operation will pose challenges in an extensible design. The current design is imperative by nature: it specifies an explicit state to move an activity to. However, a client who does not know of all the extensions that a BES service implements may not know how to pick the appropriate state to transition to. It seems better to introduce a more declarative approach in which clients specify "actions" they wish to occur, such as 'CancelActivity'. This approach would allow the BES service to make the appropriate state transition in response to a desired action requested by a client. **** Comment by Andrew on April 8, 2009 In Genesis II we have implemented sub-states for staging (in, out) and suspend/resume. I'm thinking that we should profile the substates, and add change state. A