* The extensible state model: this seems a great idea. However, I feel concerned that there are difficulties lurking there that we haven't discovered yet. Is there any prior work here that we can refer to in order to make ourselves (and others) feel more confident in the approach?
This was discussed at the telecon and hopefully reflected in the tracker. My initial interpretation was 'adhoc' extensibility but (thankfully IMHO) this could be better described as state model profiles, i.e. one state model will probably not fit all implementation/scenarios therefore several defined models should be profiled. From discussions there should not be that many... but it would allow implementations to have a defined state model if they offered suspension, but they could still produce a BES compliant implementation if they did not and have a defined state model for it.
* Information model: I certainly think we need an information model. On the other hand, I wonder if we might want to think about pulling the details out as a "profile." What we have is just what we need for our current HPC use cases; on the other hand, if one is modeling say a Java container, they might be less appropriate. Thoughts?
The current model in the spec. was felt to enforce/expect too much homogeneity. Altering it to support vectors of description sets was felt essential. Alongside that to have a well defined and required minimum set up then to let communities define additional parameters to be introduced as extensibility elements. For later standardisation
* Management operations: we currently have a couple of operations ("start/stop accepting requests") that are really container management rather than job operations. Could we separate those out in a distinct port-type?
In my view they need to go in the spec, and are different from the generic management activities you might have on a container (i.e. stop the container). If the are rendered into a different port type... I don't see an issue - a tracker beckons.
* I know there was discussion about how to handle single-job vs. multi-job operations in a consistent manner, but I don't know how that was reconciled.
It hasn't. It has not yet been discussed! Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Mob:+44(0)7920489420 Tel:+44(0)23 80598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK