Re: Concerns expressed by Stu Robertson

[Stu Robertson <sr...@nvisia.com>]

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 :-).

Regarding application needs for config to be a variable that _would_  
change during a user's session, here I think we need to be creative.   
I hadn't looked at the impacts of stateMap caching via id + config on  
DialogManager and grouping, so if it isn't as straightforward as I  
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  
flushing the stateMap cache when this does happen.  We'd loose any  
cached configs at that point, and from that point on the new value of  
application-specified configs would be used.  The performance cost  
would be zero since the originally cached values wouldn't be used  
anyway, and we need to re-initialize the models from the new configs  
regardless.

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.

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.

My thought is that refactoring could be done internally to the  
library.  The public interface (the TLDs) could be kept intact.   
Meanwhile we could push core functionality such as the FSM,  
configuration, and other support functionality down into java.  We  
could implement regression tests for these components, and then  
rebuild the core tags as normal TagHandlers.  Given that the RDCs  
themselves are almost identical internally, something like a  
RdcTagSupport class would do all of the work, making for a set of  
trivial core tags.  And we could very easily implement regression  
testing of each of these, either using mocks or (my new favorite) canoo.

The benefits of this in my view include:
* Improving testability of the framework.  Internals could be tested  
using unit testing.
* Simplifying extension of the RDCs through creating a JSTL-like set  
of support classes for tag authors.  Eliminate cut-and-paste  
entirely.  Core functionality can be designed using appropriate  
patterns for flexibility.  The FSM could become a Strategy for  
instance, allowing new functionality to be added by changing the FSM  
only (maybe not the best example - but you get the idea)
* All the benefits that come from having core logic in java instead  
of JSP tags: can leverage the compiler for type safety, IDE-assisted  
refactoring, more concise and readable implementation, ability to use  
tools in java space as they appear (AspectJ is a contrived but  
possible example. XDoclet for maintaining TLDs is a better one -  
would like to hear others' thoughts on that one too).

I'll have some bandwidth to work on the RDC project over the coming  
months.  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.

Stu

On Jul 21, 2005, at 4:26 PM, Rahul P Akolkar wrote:

>
> Stu -
>
> I wouldn't worry about an emotional response, its a lack of emotion  
> that sometimes gets me worried. I will probably discontinue cc'ing  
> others from the next email, if this thread continues. Ofcourse, as  
> Raman mentioned, we should go back on taglibs-dev (whenever you want).
>
> Let me begin by addressing the key questions you ask with regards  
> to my last email on the taglibs-dev list, which is what you  
> suggested we do. I suspect you are misreading the code in a couple  
> of places, though you can tell me if I'm wrong. My explanation  
> below might appear "too basic", thats only because my last two  
> attempts have failed miserably.
>
> <stu-quote>
> We do a lookup in the default (and non-overideable if you look at  
> the baseModel) resourceBundle - there is no setResourceBundle and  
> it's set from a constant.
> </stu-quote>
>
> But there is a setLocale, which updates the resource bundle (since  
> the locale dictates which resouce bundle is used to pull out  
> resources).
>
> <stu-quote>
> What does the locale have to do with anything other than for the  
> defaultConfig?
> </stu-quote>
>
> It has to do with xml:lang attributes and grammar URIs (you  
> probably want the language in the grammar to match the prompts,  
> though at times, it might not matter).
>
> Try this example from the distro (rdc-examples.war):
> usState-test.jsp
>
> Then try this:
> i18n-test.jsp
>
> Compare the VoiceXML markup on either invocation (you can just use  
> a web browser). Notice that the xml:lang attributes have changed.  
> Try adding a en-GB properties file for good measure, notice those  
> URIs being picked up for the grammars and the config.
>
> Let us separate the two remaining issues here: internationalizing  
> app-specific config URIs, and having more than one config per  
> instance. Lets start by looking solely at the first.
>
> <stu-quote>
> To get internationalization then, one would think you'd have to  
> pass in the URI of an internationalization-appropriate config file.  
> But if you look at the implementation of the tags themselves, you'd  
> find that you're out of luck.
> <snip/>
> If the "layers" approach that the RDC library supplies works, as  
> mentioned in your response to taglibs-dev, and the applications can  
> simply add this functionality, how is it that we can achieve this  
> without rewriting the ditigs.tag file -- and every other tag we  
> might want to use?
> </stu-quote>
>
> Akin to the examples from the distro above: [variable names  
> intentionally verbose]
>
> <rdc:digits id="foo" locale="en-US"  
> config="myEnglishUSDigitsAppSpecificConfig.xml" /> <!-- US English  
> VUI -->
>
> <rdc:digits id="foo" locale="fr-CA"  
> config="myFrenchCanadianDigitsAppSpecificConfig.xml" /> <!-- French  
> Canadian VUI -->
>
> which gets generalized to:
>
> <rdc:digits id="foo" locale="${userBean.locale}" config="$ 
> {configURIPrecomputedByAppForThisUserBasedOnHisOrHerLocale}" />
>
> RDC layer - takes care of i18n'zing the grammar and xml:lang  
> attributes.
> App layer - takes care of i18n'zing the prompt URI, which in this  
> case, is an app-specific resource, and the RDC layer just uses it  
> as an absolute URI, with no i18n treatment (as you noted).
>
> <stu-quote>
> I implemented this last week. It does not work. The RDCs cache  
> configs based on their id only, as shown in the example above  
> included in boilerplate from every RDC tag.
> </stu-quote>
>
> If we're still talking about the first issue, I don't see why not.  
> The caching is per session, so when the US English user calls he  
> gets a fresh instance of date foo and when the French canadian user  
> calls, he/she gets another. Notice the bean is created in page  
> scope and cached in session scope.
>
> <stu-quote>
> Given that this id is an absolute URI, where exactly is the support  
> for i18n?
> </stu-quote>
>
> In the app. In the spirit of rapid prototyping and iterating, I'm  
> happy to look at prototypes which push this i18n in the RDC. If we  
> are going to allow the app-specific config URI to be passed in as a  
> resource key, we will also need to pass in the fully qualified  
> bundle name and the locale, and at the same time we will still have  
> to support static URIs.
>
> <stu-quote>
> I'm sorry you consider i18n support for any RDCs using non-default  
> prompts/help/no-match/no-input to be something with no urgency.  I  
> am also sorry you consider rewriting each and every RDC tag file  
> implementation to be fairly insignificant for the RDC target audience.
> </stu-quote>
>
> No urgency on my part just means I do not have the cycles to pursue  
> this right now (i.e. this week or next). More importantly, each tag  
> implementation does not need to be changed for i18n'zing  
> application specific config URIs, as I point out above.
>
> Now, coming to the second issue, which is switching configs while  
> an RDC is interacting with the user (a.k.a more than one config).  
> The way suggested we address (on the taglibs-dev list) was by  
> suggesting a two-step refactoring approach:
> Step 1) Remove the redundancy in each tag impl with respect to the  
> bits that initialize, cache and retrieve the data model (by using a  
> helper tag) -- this will help us here, and maybe in more places in  
> the future.
> Step 2) Make changes to how caching and retrieving is done in one  
> place.
>
> I can take a stab at (1), when I have an opportunity.
>
> <stu-quote>
> If we change this to store/cache the model using 'id + config' then  
> we have the ability to vary the config according to locale or other  
> application-specific reasons.
> </stu-quote>
>
> This has implications to aggregation (group) and composition (RDC  
> composites) as well. Have you thought about these implications? I  
> do not understand this approach, because I think of this as one  
> model, many configs not many model-config pairs. But ofcourse, I'm  
> open to looking at any working prototypes.
>
> Finally, as I (and then Raman) pointed out, depending on how fast  
> we make progress, the next RDC release might be sooner than you  
> think. True, we could have waited for perfection before making any  
> release, but someone once told me that has a NP-hard solution.
>
> -Rahul

Re: RDCs - next steps

[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

RDCs - next steps (was Re: Concerns expressed by Stu Robertson)

[Rahul P Akolkar <ak...@us.ibm.com>]

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