Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[vtp-dev] Re: Evaluating VTP

Hi Tyler,

Thanks for your feedback to my list of questions it has been very helpful.
To clarify the points that I did not make to clearly regarding the
returning canvas calls, this is basically procedural calls made to other
canvases. Hence for this to work a stack of calling modules and state
would need to be maintained implicitly, instead of relying on wormholes to
explicitly detail the return functionality. So you graph would contain a
module that would ‘validate pin’, the validate pin module would enter into
the validate pin canvas perform it’s processing then return to the calling
point on ‘return’. This canvas could then be reused in it’s present form
(without having to explicitly add exit and re-entry wormhole pairs and the
accompanying logic to select the wormhole pair).

I look forward to seeing the tutorials as they come out, they are
ultimately the best way of promoting an application from a development
perspective.

And to whom ever is writing the realtime callflow tracing functionality to
visually trace a callflow as it is executed within the runtime environment
- Code faster. This functionality would be really cool;-).

Best Regards,

Blaise.



> Send vtp-dev mailing list submissions to
> 	vtp-dev@xxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://dev.eclipse.org/mailman/listinfo/vtp-dev
> or, via email, send a message with subject or body 'help' to
> 	vtp-dev-request@xxxxxxxxxxx
>
> You can reach the person managing the list at
> 	vtp-dev-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vtp-dev digest..."
>
>
> Today's Topics:
>
>    1. Evaluating VTP (Tyler)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Jan 2007 08:58:44 -0800
> From: "Tyler" <tyler@xxxxxxxxxxxxxxx>
> Subject: [vtp-dev] Evaluating VTP
> To: <vtp-dev@xxxxxxxxxxx>
> Message-ID:
> 	<5780D033175834459D174EF240286AF601C88762@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Blaise,
>
> Listed below are the questions you had regarding VTP, answers are listed
> below the question.
>
>
>
>
>
> Q) Can the openVXML editor, persona editor be modified to act on
> callflows
>
>
>
> in the standard web projects file structure? This would allow all app
>
>
>
> components e.g. Callflow, VXML, grammar files, media files, JSP, and
> Java
>
>
>
> to exist within the same project.
>
>
>
>
>
>
>
> A) Not at this time.  We are researching the possibility of adding the
> web project nature to our application and persona projects.
>
>
>
>
>
>
>
> Q) Would it be possible to have multiple callflows within a project? The
>
>
>
> reason that I ask is although callflows are powerful they don't readily
>
>
>
> allow several developers to work on them concurrently. This would allow
>
>
>
> the callflow to be componentized, and procedurized.
>
>
>
>
>
>
>
> A) Our current direction is to continue only having one application per
> project.  This simplifies deployment of single application changes in
> large enterprise distributions.  We will be addressing the issues around
> multiple developers working on a project in an upcoming release.
>
>
>
>
>
>
>
> Q) Could the callflow be extended to handle returning canvas calls? It
> can
>
>
>
> be done with wormholes but if you have many exits to one canvas it is
> hard
>
>
>
> knowing where to return to, you tend to end up with lots of global
>
>
>
> variables and lots of additional elements.
>
>
>
>
>
>
>
> A) This sounds interesting though I'm not entirely sure if I understand
> the question.  I'd love to get some more detail wrapped around this.  I
> agree that the current method of wormholes can cause graph clutter and
> would certainly entertain any ideas to reduce or eliminate this.
>
>
>
>
>
>
>
> Q) Could modules with entry exit points for JSP pages be added? So that
>
>
>
> the callflow could act in the role of front controller allowing JSP on
>
>
>
> occasion to handle the more complex vxml rendering tasks, especially if
>
>
>
> this involved generating complex javascript enabled vxml forms for the
>
>
>
> voice browsers, to reduce the number of Browser -> Server fetches.
>
>
>
>
>
>
>
> A) This functionality has been developed and will soon be added to the
> source repository.  A new built-in Subdialog module will be available
> that allows just that.  It can also be used to integrate other
> third-party modules, such as Nuance OSDMs and IBM RDCs, into your
> applications.
>
>
>
>
>
>
>
> Q) How do you embed java behind the callflow, is this possible...
>
>
>
>
>
>
>
> A) Absolutely.  There is an API (org.eclipse.vtp.framework.api) that
> allows you to build custom modules to use in your callflows.  If you
> have looked at the source for any of the built-in modules, you'll see
> that they use the same API and offer at least a starting point for
> learning its use.  A custom module construction tutorial is also in the
> works and will be posted to the website.
>
>
>
>
>
>
>
> Q) Is the callflow xml object model available to be manipulated in java?
>
>
>
> This is necessary for dynamic tasks such as substituting prompts
> depending
>
>
>
> on state.
>
>
>
>
>
>
>
> A) The contents of the XML document are not available for programmatic
> modification.  Many types of dynamic user interaction and back-end
> system integration can be accomplished using custom modules.
>
>
>
>
>
>
>
> Q) What is required to adapt the xml meta model for different browsers
> at
>
>
>
> runtime?
>
>
>
>
>
>
>
> A) There is an abstraction layer that provides concrete implementations
> of the basic interaction elements, such as field and menu, based on the
> voice browser being used.  This abstraction is still relatively new and
> will be expanded to include various platforms out of the box.
>
>
>
>
>
>
>
> Q) For debugging purposes would it be possible to enhance the tools to
> be
>
>
>
> able to trace a callflow as it was executed within the runtime
> environment
>
>
>
> as it was executed, visually from within the eclipse VTP client
>
>
>
> application.
>
>
>
>
>
>
>
> A) This is another very good idea.  We are working on adding integrated
> debug capabilities to the tool set including visual tracing.
>
>
>
>
>
>
>
> Q) Where should I check out the VTP source from is it under the WTP cvs
>
>
>
> tree, has the openVXML code been added into the VTP source tree yet.
>
>
>
>
>
>
>
> A) The openVXML codebase is available from the VTP source tree.
>
>
>
>
>
>
>
> Any Feedback would be much appreciated.
>
>
>
>
>
> Tyler VanWinkle
>
> Product Manager
>
> OpenMethods
>
> 4741 Central Street  |  Suite 285  |  Kansas City, MO  |  64112-1533
>
> o| +1.816.283.VXML (8965) x118  c| +1.816.808.2523
>
> Tyler@xxxxxxxxxxxxxxx  |  www.openmethods.com
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://dev.eclipse.org/mailman/listinfo/vtp-dev/attachments/20070111/aebc711a/attachment.html
>
> ------------------------------
>
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev
>
>
> End of vtp-dev Digest, Vol 19, Issue 2
> **************************************
>



Back to the top