Hi again On Fri, 30 Sep 2011, Tomohiro Kudoh wrote:
The state machine matrix follows the current design of state machine. The "prov.rq" message sent at the Auto-provision state is for children, to propagate the provision request. In the current design, no prov.cf is returned to the requester at the time a prov.rq message is received if it is before the start-time. The SM silently transits to "Auto provision" and then transits to "Provisioning" at the start-time. It returns prov.cf or prov.fl when actual provisioning is succeeded/failed at the start-time.
OK, I think I get it now. I missed the part about propagation to providers. It is a bit tricky to infer if a message should be issued back to the requester or down to a provider, as it is not clear what role the state is being handled for. Another issue with the state machine, are the "holds". These are not really possible to do in a state machine as it requires the addition of a queue construct. I am not quite sure how to handle this, but with them, it is not actually possible to implement this as a pure state machine for handling requests. This is more a generic protocol issue, but I am not thrilled about the state updates to auto-provision and scheduled being silent, i.e., the requester isn't notified when the state changes into this. I've previously suggested making a generic stateUpdated / stateChanged message from provider -> requester for these things, which could be used for all provier -> requester communication (except query of course). Some of these things should probably have been in a seperate mail to the list, oh well. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.