I think we need to plan on leveraging the multiple feature structure. There are some package refactorings that need to be undertaken before it can be rational. For right now it makes sense to split the runtime, desktop, and launching/debug components into separate features.
Down the road, we need to look at making a bright-line division between the base runtime and ui frameworks and those targeted at VXML based voice applications. The framework is capable of supporting other interaction modes, such as Instant Messaging. There has been some creep of the VXML subsystems into the underlying structures that need to be extracted, but otherwise the separation is there. You can see this intent in the .core and .voice versions of some plugins. Taking this into account I see a feature set that encompasses this capacity. We also need plan ahead for support for internationalization of both the voice projects for multi-lingual applications as well as full internationalization of the IDE interface as well. Do you guys have any ideas how we would want to manage that aspect of the system as well? Trip Gilman On 3/31/09 4:16 PM, "Dr. Dirk Schnelle-Walka" <[email protected]> wrote: > Hi Mike, >> I think "features" should be aligned along dividing the deliverables >> into pieces of functionality that are/can be separately loaded and >> used without requiring all features to be present. So far as I know, >> VTP does not lend itself to that, so probably there should be only one >> "feature". > The debug feature can be used without the others. So I would vote for > multiple features. > > ~dirk > _______________________________________________ > vtp-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/vtp-dev _______________________________________________ vtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/vtp-dev
