was thinking... well, thanks for saving me time. One thing that's
probably safe to assume about almost all application requirements
that require the prompts to shift within a session (in our case, the
user has to switch to DTMF only; input-mode is set to disable voice
grammars reducing impact of noise, and prompts shift to give DTMF-
only instructions) is that this won't happen very often within a
session. At most, once. I'm wondering if we could support this by
<snap/>
Here is my suggestion. As a pre-requisite, we will need to add a
"channel"
attribute to each RDC (or whatever attribute name we choose), which
can
take values "voice", "dtmf", "both".
Then:
1) Think of this as a multi-channel application [channel 1: "both" (or
"voice"); channel 2: "dtmf"]. How familiar are you with the source
of the
multi-channel sample application? This will be similar, just
easier ;-)
The views will appear identical to the model, each once will take
different value of the channel attribute and different configs for the
RDCs (according to its channel). A channel switch (to dtmf only)
will be
enabled by a consistent VUI defined via a JSP fragment (see
header.jsp and
footer.jsp in sample application -- press * in your example). Start
with
channel 1, if the user requests a switch, hop on to channel 2 (in
fact you
can go back and forth as many times as you want; even though its
true that
this will probably be used at most once).
2) In order to collapse the two views, we will have to add
functionality
on top of (1) to support more than one configs; similar to how RDCs
support more than one grammar. This will mean that the channel
attribute
will not only dictate what grammars are active, but also what
config is
chosen.
For (1), we don't need to think about more than one configs per
instance;
but (2) goes further, we don't need to think about two views.
Ofcourse,
(2) is more work.
Is flushing the stateMap cache simply a matter of stateMap.clear()?
If this or some variation works, then we can meet our requirements
this way.
<snip/>
Clearing the model / state will probably not do it, because the
state is
required to remember where one is in the dialog (within a JSP). More
importantly, conceptually, the voice+dtmf -> dtmf-only transition
does not
constitute a loss of state.
Let's talk about the other issues I brought up when you and your team
have time after the first release. Now that I see that the RDC
project does meet i18n requirements, my hesitations about a 1.0
release are gone. But I do think that the RDCs would benefit
substantially from a bit of refactoring work. Not because of
quality; I haven't found many bugs at all. My primary issue with
the existing implementation is that the widespread use of tag files
hampers reuse, complicates unit testing and leads to other
limitations I brought up in my earlier email. I'm curious what
others think about this.
<snap/>
Your comments are well received; in fact, we might just have to use
Java
impls in some places for various performance / testing / extensibility
reasons.
But I will point out one thing -- there is much beauty in sharing
the same
programming model for implementation and instantiation of a custom JSP
tag. In the spirit of JSPs in the first place, and tag files with
JSP 2.0;
let me say that authoring:
<foo bar1="${bar1}" bar2="${bar2}" />
beats, hands down, having to author:
buf.append("<foo bar1=\"").append(bar1).
append("\" bar2=\"").append(bar2).
append("\" />\n");
...
out.write(buf.toString());
Hopefully, I escaped by double quotes right up there. Ugh ...
I will be quite disappointed if we end up authoring, say fsm-input,
as a
Java tag impl, for whatever (legitimate) reasons.
I think its time to push this at another level, I will open an
issue or
two on jsp spec public when I get some cycles; that should stimulate a
discussion with the spec team (which might be a more appropriate
forum).
My thought is that refactoring could be done internally to the
library. The public interface (the TLDs) could be kept intact.
<snip/>
Very true, especially since if we change the public interface, the
next
RDC release candidate (whenever that is) will need to be a 2.0;
otherwise
we can call for a 1.1; I'd prefer the later, if we can.
Meanwhile we could push core functionality such as the FSM,
configuration, and other support functionality down into java. We
<snip/>
The benefits of this in my view include:
<snap/>
Sure, there are all those benefits.
I'll have some bandwidth to work on the RDC project over the coming
months.
<snip/>
Great, what do you think about (1) and (2) above for the issue that
you
want addresssed (swtich to dtmf only)? Would you like to prototype
that?
Let's talk about design when you have time. I'm curious to
know what the core team has in mind for the library, and what it
thinks about how we can make it even better.
<snap/>
Short term, we plan on introducing an additional dialog management
strategy implementation or two for rdc:group, and also some
refactoring
under the hood.
-Rahul
Stu
