You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Rahul P Akolkar <ak...@us.ibm.com> on 2005/07/24 18:39:18 UTC
RDCs - next steps (was Re: Concerns expressed by Stu Robertson)
On 7/22/05, Stu Robertson <sr...@nvisia.com> wrote:
> Thanks Rahul :-)
>
> You are right about i18n of the config attribute. The fact that it's
> cached doesn't matter since in the case of i18n, the config set as an
> application-space variable would never have more than 1 value in a
> user's session. The layers principle holds: the taglib doesn't
> prevent this from happening (my concern). So, as I hoped, I can
> apologize on that one (though it's nice that you and your colleagues
> think I don't have to :-).
<snip/>
Not a problem :-) If you feel like it, take a stab at improving the i18n
tutorial on the wiki. I wrote it, but it often helps if someone other than
the author writes the documentation.
> 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
Re: RDCs - next steps
Posted by Stu Robertson <sr...@nvisia.com>.
But is this more complicated that it needs to be? The voice grammars
are deactivated with the inputmode property in normal voiceXML, so I
don't think we'd need to introduce a channel concept for that since
app space can handle it.
The remaining bit is overcoming the current limitation that once a
config is initialized, the config attribute is not checked. That's
part of what you list as two. We could support it by allowing
multiple config values to be cached per instance. Might be overkill
though, since in all of the use cases we've thought of so far, only
one value for config is needed - when the value changes, the previous
value will never be used again. Or we could provide some mechanism
to "flush" the config caches such that the tags will initialize again
when the JSPs render. You mentioned earlier that just clearing the
stateMap would interfere with the grouping and aggregation. If the
clearing were done in controller logic - outside of JSP rendering, is
this still true? That is, would the next JSPs that rendered consider
this their first time in the session? It would be nice if we could
do something simple like that, as it would give application space
more freedom to control this directly. I need to look over the
implementation more carefully still.
Now time for bed... More later :-)
Stu
On Jul 24, 2005, at 11:39 AM, Rahul P Akolkar wrote:
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org