Adam Lally wrote:
More thought on the flow controller / flowConstraints topic:
I think there's a fundamental question here as to how the flow ought
to be specified, now that we've opened things up so that the flow
specification might take a variety of forms, not just a flat list.
Do we want to:
(a) support specifying the flow through the FlowController's
configuration parameters
OR
(b) support extending the <flowConstraints> section of the aggregate
descriptor with new kinds of flows in addition to <fixedFlow> and
<capabilityLanguageFlow>. We might even imagine a <customFlow> that
could be filled in with arbitrary XML, it being the FlowController's
job to make sense out of this.
An advantage of (a) are that we use the common configuration parameter
mechanisms we already have, so for example we could use the same GUIs
we use for setting other parmeters to also set the parameters on the
flow controller. (In contrast, if we allow arbitrary XML, the user
would need an XML editor to be able to edit the flow.)
Advantages of (b): It's closer to what the user already knows. It can
be much less verbose than using configuration parameters (which also
require overrides in the aggregate if the flow is to be specified
there). If there's already an XML syntax for the flow it could
potentially be used directly. (Although this last could also be done
with an external resource referring to a separate file containig the
flow definitions.)
I prefer (b). I think the users already know how to specify a flow and
it seems to be easier for me to specify
the flow using the flowConstrainst than using configuration parameters.
I'm currently not sure what will be the best way to do this, but we
should try to get feedback from out users/community what they think
about this. Do we know anyone that is already using
custom flow controllers?
-- Michael
