While looking for info in groove integration exampes I stumbled on this post:

Date Posted: May/10/2002 11:02 AM

Posted By: philking (Member)

Moderator,

Also checked the controller and noted that is shutdown fine there. The sample controller code is too simplistic to use as any sort of meaningful test. Note that opening tools as per the sample doesn't allow the tools to work at all!

If GN is serious about selling Groove for controller use then that comittment should be evident through the samples and adequate beta testing in the contoller environment. This would also be an excellent test for the API classes which like any good class structure need to work independently of any UI or Tranceiver specifics.

Controller apps could end up representing a huge slice of the total user base of Groove technology. Currently the transceiver and standard UI components are far too limiting for powerful app developent. This shows through all tools currently available and the time, effort and cost to produce such mediocre functionality. The end result is that users come away less than impressed with Groove. Indeed many are reluctant to use it because the interface and functionality is far inferior to which users are accustomed in most windows apps these days. To understand why, one can simply look at the ListView component. It's functionality is so crude it wouldn't register on a feature comparison chart up against mature ActiveX grid controls on the market today. Sure we can sort of wrap ActiveX in tools but that does NOT deliver the performance or functionality of a component designed to be hosted in an ActiveX container totally integrated into COM.

Personally I believe developing Groove apps in a mature environement supporting native ActiveX containment is the way to go. Rich and diverse functionality can be delivered at RAD speeds providing the API doesn't choke developers efforts along the way.

GN marketers need to remember that no matter what hosts Groove technology, the Tranceiver or a Controller, a Groove license sale is a SALE! Controllers need more attention. Please bring this crucial issue up with GN management and help Groove proliferate to every desktop.

Still with grand hopes for Groove ...
Phil


05/10/2002 11:18:34

This post resonates with my concerns about groove's busines model. As much as I'm excited about groove's technology, collaboration should remain a feature of a desktop application. Collaboration framework/platrofm like groove must avoid making ISVs re-write their existing applications just to enable collaborative workflows. Even less groove should try to re-write those apps themselves!

I'm sure we all want to see superb collaboration functionality in something like Adobe Photoshop to take one example. Does groove seriously beleive that adobe will re-write their system to be hosted inside groove's UI?

What's more worrisome is the fact that some of groove partners seem to buy this strategy. They seem to beleive that groove is their golden opportunity to leapfrog established competition.
Let me pick on Virtual Methods UML Tool. Forget collaboration for a second. How does the UML modeling funtionality of this editor compares with competition (Visio, Rational Rose)? I think UMLTool is doomed because of very strong compatition it faces.

The bottom line: Fantastic technology like groove will not cause people to abandon their favorite tools. Groove should pay more attention to integration into existing applications.