Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[vtp-dev] Questions, directions, techie stuff

Hi,

First, let me (re)introduce myself.  David Reich, formerly of IBM.  I was involved in the creation of VoiceXML and was the guy who was the initial driver behind all of the Eclipse-based voice tooling, first from IBM's toolkit, and it's subsequent donation to Eclipse and VTP.  I've since left IBM and as you know, IBM's involvement in voice has waned.  But, I am now with a new company, happily back in VoiceXML, CCXML and SRGS, and we are doing a lot with VoiceXML and CCXML and I was brought in to drive our development team, and one of the areas I am looking at is the development of our application artifacts, and VoiceXML application generation.

With that, I've spen the last couple of days figuring out where things are with this project, how we can use it, how we might give back to it and so on.  From what I've been able to see thus far, it looks like the current code base bears little to no resemblance to the VTP 1.0 code that came in from my former team, but, on the other hand, there is a nicely-coming-along visual editor without which all VTP would be is the XML editor with DTDs plugged in and while nice, not really compelling.

I was hoping to provoke some discussion and see about some combination of code to create an even more gener(ic)ally useful environment.  With that, some thoughts and the hope we can put some other things together.  In no specific order:


 *   The original IBM code seems to be gone.  When things moved to SVN, the CVS repository went away, so unless someone has that source code, it's gone forever (I've checked with the (remnants of) the IBM team, and without some serious effort, it's not readily available.  So, how can we get that back, even if we only want to take small bits (or even none?) of it?  There's got to be useful things there, and we should still look at that.


 *   In the original tools, of which the VTP 1.0 code was a part, the vision was a call flow builder similar to what WebMethods has been working on, but rather than generate a metalanguage, have it generate VoiceXML and have a tabbed view (kinda like FrontPage) where you see the call flow view, and the VoiceXML source view, and the editor would allow you to tweak the VoiceXML in source edit mode, affording finer-grained control of the VoiceXML.


 *   Linkages to the Eclipse framework for task-list items in validation, warnings, errors, etc.


 *   Enabling (as Randy has told me is the direction) a derivative or extension plugin to generate code that spews forth VoiceXML.  This could take the form of the OpenMethods servlet, or even perhaps an extension one could write

to do JSPs, or other types of markup/tag/metalanguage since not everyone will want just the VoiceXML from the OpenMethods servlet, or wants to make further tweaks to the VoiceXML.


 *   A broader property sheet for each call element in the palette on the canvas to specify items such as barge-in, SSML tags or information, prompt audio files to be played and so on. Specifically, the block would play one of a set of prompts based on current state (such as "Welcome to..."  or "Welcome back to..." based on some global variables in the ECMAscript for example.  This tool should should hopefully allow for the export of this property sheet data in different formats, but then again, as open source, we can work together on extensions for our specific needs and write the hooks and extension code for different needs.


 *   Have the palette be extensible where one can take prebuilt modules (say an authentication subflow) add them to the palette, and drop it into a new or existing application.

That's enough or now, but you get the general idea.   I'm hoping we can make this a bit more granular and extensible, and some of that is in the earlier code (yes, I also have a fondness for my baby ;-) and marrying that with the newer code, I think we can do a lot here.

Comments?

Thanks....

David Reich
AIT Architect,  Adeptra, Inc.





Back to the top