Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [vtp-dev] Project Software Layout

Perhaps I'm being overly sensitive on naming, but IMHO, this is the Voice Tools Project, and OpenVXML is a name that (yes the ones who are carrying the lion's share of the work) OpenMethods uses as "it's" name or brand.  Kinda like IBM using Eclipse as the foundation for Rational tools, but not trying to rename the Eclipse workbench as the Rational development platform.

I suggest we keep the VTP as VTP, and any branding should be done by any distributions from someplace other than Eclipse.  Nothing wrong with OpenVXML based on VTP as a distro from Trip and Co, but the perception that this is not a pure Eclipse project may creep in there.  As is evidenced recently when I rejoined the project, it's confusing as to the difference.  VTP is an Eclipse project.  OpenVXML really is not and how we disseminate the code should reflect it.

That said, I think the Voice Tools Project as the VoiceXML (or interaction) development platform with a VTP SDK for those wanting to extend it further is a good idea.



David Reich



________________________________
From: Trip Gilman <trip@xxxxxxxxxxxxxxx>
Reply-To: Voice Tools general developers <vtp-dev@xxxxxxxxxxx>
Date: Sat, 2 May 2009 20:10:30 -0400
To: Vtp-Dev <vtp-dev@xxxxxxxxxxx>
Subject: [vtp-dev] Project Software Layout

I'd like to propose a change to the way we package the various elements of
our software.  I think we should go ahead and separate the SDK type features
of the software from the main development environment package (OpenVXML).
This would result in a top-level component named OpenVXML that would include
the visual design environment, server runtime and web app exporter, and the
launcher.  The elements floating around to allow developers to extend the
platform would be gathered into a new top-level component called either
Voice Tools Project SDK or OpenVXML SDK.

The split would not only encompass the codebase but the documentation
elements as well.  I think this will highlight some of the architectural
features inherent in the framework (such as support for other interaction
types) otherwise hidden away when packaged into OpenVXML.  Current SDK items
would include the wizards for creating Voice Formatter projects,
documentation and wizards related to building custom modules, and any
elements associated with supporting other interaction types.  This component
could also host any efforts to expand the export types of OpenVXML or other
packages based on the codebase.


Trip Gilman

_______________________________________________
vtp-dev mailing list
vtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/vtp-dev



Back to the top