| Re: [vtp-dev] Questions, directions, techie stuff |
|
Hi David, just one more comment about the old code: The only part that I am aware of that moved from the old repository to the new one is the debug facitily. I am still working on that for the JVoiceXML support. ~dirk Hi Trip Yes, this brings together (more formally stated) the things I was assuming from watching the evolution as I read through the mailing list and newsgroup archive. I was also trying to bridge what IBM had done in it's own Voice Toolkit versus the tidbits that got contributed (BM has way more than got contributed so I needed to digest what did and did not go to Eclipse). So I think from my inferences, and reading your reply that it is safe to say that essentially, the IBM code contribution was the base editors built on WTP (which actually was needed at the time because the XML editing framework was missing a number of features), and now that the XML framework is better that shoving the SRGS, or VXML or CCXML DTDs at the editing framework now will do essentially the same thing - right? Assuming that, I'm starting to feel a little warmer and fuzzier. My next question though, is this metalanguage and common runtime architecture you describe. Is this part of the tooling? Or some runtime from OpenMethods that is required in a server environment and the application/interaction with the user as described by the metalanguage is only useful with this generator at run time? I hope it is the former. I like the idea of the interaction model, and that one can use it for SMS as well as voice etc, but I wonder about the rendering model, and hope it's just my learning of how the current VTP is built, but as you pointed out, every consumer of user of this tool will have specific language requirements, for example, it I use VoiceGenie vs IBM Voice Server vs... because for my VoiceXML, I will have specific subtleties (notice how I do not say Nuances? ;-) in what I want generated. Also, in my specific case, we do not use JSPs, but a JSP-like mechanism and would want to hook in to render this other language as the target (we have a framework that consumes this with some VoiceXML embedded in it, and it generates other VoiceXML and CCXML) and would like to be able to write a module that generates our "markup" as well. If this is part of the tooling, great. Is there any doc available yet on that? Or is this what Randy was referring to? I wonder if we can start a weekly call perhaps, since I'd like to see about regenerating interest in this tool, especially when you have positioned it as a user interaction modeler as this could have other benefits in other areas such as multimodal/text messaging (e.g. Yap) or others. Also, a little more efficient than the mailing list at least to get things moving across multiple parties again. Whaddayathink? David Reich AIT Architect, Adeptra, Inc. ________________________________ From: Trip Gilman <trip@xxxxxxxxxxxxxxx> Reply-To: Voice Tools general developers <vtp-dev@xxxxxxxxxxx> Date: Sun, 12 Apr 2009 20:27:01 -0400 To: Vtp-Dev <vtp-dev@xxxxxxxxxxx> Subject: Re: [vtp-dev] Questions, directions, techie stuff David First I'd like to thank you for your interest in the VTP and welcome you back to the industry. I've provided a broad overview of where we are now as a project and also weaved some of my detailed thoughts on your questions into your original text below. You are correct in that the current VTP is a complete departure from the codebase originally contributed by IBM. I would like to take a moment to point out some of the fundamental changes between the original vision and our current direction and then discuss the reasoning for our approach. First, the xml editors for GRXML grammars have been replaced with the generic xml editor provided by the basic eclipse development framework. The original VTP utilized a customized xml editor based on those provided by the Web Tools Project. The removal of this dependency reduced the overall size of our software by nearly 100M and eliminated several layers of complexity for no real loss of functionality. Second, and probably the most centrally important, the VTP employs a common runtime architecture as opposed to code generation. I don't want to focus on the choice between the two, but I would like to illustrate how we leverage our choice of a runtime architecture. The voice tools project has almost become a misnomer. Our development and runtime frameworks are no longer just for VXML, but have evolved into a generic platform for describing interactions. The core of the development environment is blissfully unaware that the user intends to use the application they are creating as the source of a VXML interaction. The runtime environment executes the interaction within a process engine that emits basic interactive commands that are interpreted into VXML at the final moment. This is important to understand as this philosophy is pervasive throughout the codebase. The user creates applications by adding Actions to a canvas and then defining the transitions between those actions. The most common Actions, such as a Menu or a Prompt(Output), are standard components provided by the framework. However, third-party developers can easily and quickly create their own action libraries for users to use. I want to reiterate that although these actions may share the names of the elements that make up VXML, they are not the same. The designer has an abstraction framework that models the nuances of interaction types on these actions, allowing interaction specific configuration. For example, the VTP comes with an implementation of the Voice (VXML) interaction type. This provides interaction specific UIs to manage VXML settings such as barge-in and dtmf/speech entry. This framework has been used to create other interaction types such as Instant Messaging. An application can support any combination of interaction types the user has available to them. This is very powerful in that the same application deployed once, could drive the interactions of both telephone and IM based customers. On the runtime side, things are equally abstracted. As I mentioned earlier, the artifacts produced by our designer (upon export) are actually process meta-language documents. These documents are executed by the process engine at the core of the runtime. As the process is executed, interactive commands are generated. These commands are then filtered through a platform abstraction layer and evaluated. The VTP includes a platform layer designed for VXML interactions that is capable of transforming the interactive commands into their representative VXML documents. The platform abstraction layer is powerful on two fronts. First, it allows the VXML generation process to be customized to the specific VXML Browser platform requesting the document. This means that a single application instance can service multiple VXML platforms simultaneously without re-export or compilation. The VXML session could even bounce back and forth between the platforms without issue. Second, the platform abstraction is open to third-parties to add implementations for additional platform types and output mechanisms. The VXML platform generates XML documents and processes requests and responses over HTTP. Other implementations could simply execute direct API calls to other software or hardware, never producing a document artifact. They could also support transports other than HTTP. I hope this helps illuminate the project for you. Trip Gilman On 4/10/09 8:33 PM, "David Reich" <David.Reich@xxxxxxxxxxx> wrote: |