[
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
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