Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[vtp-dev] RE: A follow-up on our discussion about VoiceXMLBrowserInput.setInput(String)

Hi Brent,
 
Thanks for the quick response. I agree that your suggestion is a good way to extend the VoiceXMLBrowserInput API if no other changes are made. Your solution leaves me with the issue of how to handle the existing implementation of the setInput(String) method. It is reasonable to expect that developers will code to that API. So I will need to implement a usable, extended version of that method to stay compatible.
 
In the end, given that no change is made to the API, I will  implement some sort of technique to serialize/deserialize to a String in order to use the specified API. I doubt that I will try to extend the API with new methods since they would only be of use to internal versions of our code.
 
To be clear, my issues can be summed up more generically as:
 
a) no separation between interface and implementation of VoiceXMLBrowserInput
b) no support for complex data in setInput(String)
 
I would appreciate greatly the OPAQUE or VENDOR_SPECIFIC constant addition you propose. I think the latter constant name makes the most sense to me.
 
Best Regards,
Jeff Pedigo
720-562-4558


From: Brent D Metz [mailto:bdmetz@xxxxxxxxxx]
Sent: Thursday, December 15, 2005 8:32 PM
To: Jeff Pedigo
Subject: Re: A follow-up on our discussion about VoiceXMLBrowserInput.setInput(String)


Hi,

Glad to see the VTP is on your mind today. Feel free to cc: the list; even if doesn't turn out to do anything but provide notes on the API so someone will have something to read through on the subject when they browse the archive. I think I might not have been clear what I meant on the call; I was suggesting subclassing the object to add an all-new method to handle passing non-generic objects, ie:

public class SandCherryBrowserInput extends VoiceXMLBrowserInput {
    protected Serializable mySerializedObject;

    public void setCustomInput(Serializable s) {
        mySerializedObject=s;
    }

    public Serializable getCustomInput() {
        return mySerializedObject;
    }
}

When inputs came into sendinput() you could use instanceof to see if it's sending data types that are sandcherry-specific, and if not process DTMF and other inputs from other sources as you want to implement.

Would this provide what you're looking for? The alternative is to change the setInput() method to accept Serializable or just generic Object types instead of a string, then add a predefined type OPAQUE or VENDOR_SPECIFIC or something to that effect. The thing that would be a little tricky is if two implementations independently made some assumption about using the Object passed in, ie if two implementations pass in a vector and assume it contains different things. If someone's client control wants to talk in a specific way to its backend I think the safest route would be for them to explicitly only send the data to their own object by checking using instanceof, and at that point they might as well cast it to their own object and call their own custom functions. Actually it isn't even necessary to use VoiceXMLBrowserInput subclasses; it's just as conceivable to directly implement a new function in the implementation of IVoiceXMLBrowser that directly took the custom input as well.

--
Brent D. Metz
Enterprise Voice Tools
bdmetz@xxxxxxxxxx
"Simple things should be simple, and complex things should be possible." - Alan Kay



"Jeff Pedigo" <JPedigo@xxxxxxxxxxxxxx>

12/15/2005 06:38 PM

To
Brent D Metz/Boca Raton/IBM@IBMUS
cc
Subject
A follow-up on our discussion about VoiceXMLBrowserInput.setInput(String)





Hi Brent,
 
During our 12/15/05 VTP Conference call I questioned the implementation of org.eclipse.vtp.launching.VoiceXMLBrowserInput.setInput(String). I wanted to clarify my issue and make a suggestion on how I think the implementation could be improved.
 
First, I am proposing the following:
 
a) define an interface that defines the constants and methods you have implemented in VoiceXMLBrowserInput
b) change the method setInput(String) to setInput(Serializable) in both the new interface and the implementing class
 
This would allow us to send any sort of complex objects from the Eclipse to the VoiceBrowser and would keep your existing implementation largely intact.
 
My issues can be summed up as:
 
a) I don't want to override or expose a setInput(String) method since we won't end up using it to send our input
b) I don't want to serialize to a String at this level (it is being serialized at a much lower level in our Eclipse-to-Browser protocol)
 
I'm happy to post these comments on the mailing list but wanted to float them by you first to minimize any public confusion.
 
Best Regards,
Jeff Pedigo
720-562-4558

Back to the top