1. Skins to replace look-and-feel of Groove transceiver (stretching the meaning of "app" but let it go). End-users.

2. Property-specializations of existing tools (apps). Power end-users.

3. Assembly of new apps (tools), primarily by scripting new behaviors for existing Groove components (using Python, Javascript, VBScript et al). Light programming.

4. Widespread availability of hundreds of existing Active-X controls wrapped and made "groovy" (these will also feed growth of 3. above). For instance, PowerPoint control(s) for sharing presentations. Light programming.

5. Creation of new COM components to build native Groove applications and support activities above (C++, VB). Programming.

6. Porting of existing desktop apps to run within/under the Groove platform and UI (yes, Microsoft Office type). Serious hacking.

7. Native Groove applications, whether built over Groove transceiver or not. Serious hacking.

The key is that all of these will be "groovy" (ie, support sharing of deltas on P2P basis and utilize other core Groove services).

One of the critical divergences from Notes, based on their hard experience, is the complete decoupling of Groove UI from the lower layers (core components, engines) as per support for 7 above. Taking a trivial instance, looking at the current Groove UI, nothing prevents the awareness panel (buddy list) from running as a separate UI desktop window. As a corollary, expect Groove's own UI team to supply optional user interfaces to support multiple models of "grooving".

So, looking at Userland stuff,

1. Groove could be integrated to Userland products by transmitting data between the two platforms. Useful but not terribly interesting.

2. The outliner (for instance) could be offered as a simple replacement for Groove outliner. Likewise for other cool Userland components.

3. Frontier or Manila or RU could be integrated to run in toto within the Groove UI.

4. Frontier or Manila or RU could run over Groove services, without any reliance on Groove transceiver UI (ie, supply their own UI but rely on Groove communication, account/identity, security services).

5. Or, any combination of 1 thru 4 above.

For extra credit ;-), RU could be staged to become a standard IDE for Groove. Given the extreme XML-centricity of Groove plus XML-RPC and SOAP support, this could embed Userland profoundly into the still nascent Groove development community.

Russ

Very nice summary of possible Groove/RU-integration.

I am currently hacking at things that might be useful for level 1 + 2. First things first.

But once you start thinking about higher levels of integration, the important question is: what do you need?

There are many possible answers. Me, I am into this for a very simple reason: I really want to share outlines written with RU over the Net. For many years I have used outlines to communicate professionally - so using the best tool myself makes very good sense.

But what does it take before I can ask a customer (especially a new customer) to share stuff over the net? I need something that is extremely simple and very secure - and if the customer has already heard of it, that's even better. These are factors that might eventually make Groove an easy sell.

Before I can introduce more sophisticated ways of working, I need an easy but secure way of communicating. As soon as the infrastructure exists, tools like RU and Manila immediately become much more important.

Ray Ozzie talks about enabling people at the edges of organizations - that's me (and possibly you, since you hang out here :-)). One way to do that is to make it easier to use the good tools we already have.

Well, we'll see what happens next. These are interesting times.

Well, to some of us, it's not only useful, but VERY interesting. Communication between RU and Groove should let us utilize the strengths of both worlds, and avoid the weak spots, for the least programming effort.

Very interesting indeed. And using "the least programming effort" is important - no one wants to re-implement tools that work.

Note Dave's disclaimer when he linked to this thread: "I don't see any point in porting Frontier into Groove, that would be monumental, and not particularly interesting to me."

On the other hand, Russ idea to use Groove services without the Groove GUI would indeed take serious hacking - but might be worth looking into.

Of course, it remains to be seen just how well the Groove services work in practice. People sent me instant messages via Groove today, and I tried to answer most of them immediately. But in several cases it took 1-2 hours before Groove even confirmed that my reply had been sent - that's not exactly "instant" instant messaging.

In the long run, it is all a question of what "integration" comes to mean.

I would appreciate the opportunity to use the elegance, power and flexibility of RU in a "groovy" fashion - within shared spaces and utilizing the other Groove services. The outliner, minimally but ideally, other components as well - the database, ability to script Groove or interesting aspects of it (including its components), etc.

As you wisely point out (Jonah has too, I think), the best course for now is to get the largest leverage with the least effort - and avoid the many weaknesses of Groove's early implementation. I think I said that the more complex applications would emerge over time? Two to five years is probably the right time frame for them. Meanwhile, all of us have plenty of work to do, in and out of Groove.

However significant Groove may be (and I think it extremely significant), the two-way Web hardly goes away. I think Groove has left that door wide open for Userland, as a matter of fact, if integration is pursued agressively.

The early versions of Notes never really conceived of the vast Domino/Notes installations that emerged over time. Groove's scalability is likely to be suspect for quite some time (guilty until proven innocent). They wisely focused on small team collaboration as a starting point. OTOH, the Groove design has thoroughly anticipated massive scaling (or at least that's the narrative). Think tens of millions if not hundreds of millions of users, huge shared spaces, heavy multi-platform and multi-device support - and the requisite apps to service that.

This is hardly tomorrow - more like five to ten years. But that is the roadmap. It will also bring Groove ultimately into a collision course with platforms like Notes, Exchange and .NET - email or no email. There are only so many ways and environments within which people will "live" - usually, the acceptable number is "one of two".

Groove is the first product in a long time, if ever, that has made me think "That app is worth buying a Windows box for."

That's a strong statement for me. I'm a Mac user, I share a room with 12 of them. You can't imagine my disappointment on learning that there was no Mac version.

Just by chance, I do have a Windows box on the premises, running NT4 on a Dell PowerEdge, which I'm installing Frontier on. I don't like the UI much, but it's good enough. I can imagine that Win2K on a Vaio might be quite pleasant. Portable, connected and synchronised -- damn fine.

But it's not about platform wars, just economics -- I guess the most expensive part of porting Groove to Linux or MacOS 9/X would be the GUI, rather than the networking, encryption, and so on.

It highlights the need for a cross-platform UI builder/toolkit. P2P apps need be ubiquitous (at least potentially) and accessible from multiple platforms, just as web browsers are.

Any vendor who can deliver that seamlessly will make a lot of money. If Groove can do it, they'll have a real winner.

I might still get a Vaio to run it on!

In the short-term, there is plenty of stuff we might look at if we want "the opportunity to use the elegance, power and flexibility of RU in a "groovy" fashion". I want that, too.

But in the long-term, I am not sure if scalability on a level to compete directly with .NET, Exchange etc is really interesting - even if hinting at it may be a good narrative to generate hype and money. The players on THAT arena already exist - why not let them fight it out?

What interests me about Groove is exactly the idea that small groups of people could do serious distributed work without having to worry about large-scale infrastructure at all.

I spend some of my time in corporate environments. And it's always interesting how large Notes-installations become bogged-down legacy systems - but are still seen as enabling by most users. The need to collaborate in an easy, more unstructured fashion has always been there - and if Notes is the best way to satisfy that need, so be it.

But when it comes to working both inside and outside large organizations, Notes doesn't help much - even if the people who want to work are just a small team.

That's the kind of solutions I'm looking for. And tools like RU and Manila help right now.

Groove apps are pitiful at present - basically demo's - and advertised as such. For public attribution, Jack Ozzie told me they can't wait for developers to replace them; the sooner the better. Their mission is the platform and enabling other developers to do the great apps and applets.

I also agree 100% with you about Web and content.

I have a strong conviction about a particular application type that could (should, imho) (re)connect Groove to the two-way Web model - waiting on some feedback from Groove before I talk more. Perfect for Userland imho but up to all you developers to decide ;-).

Groove correctly saw that the Web was overloaded for certain types of collaboration (Jon Udell is much better at explaining this than I am). But this doesn't mean the Web is now passe or is played out. Duh.

I'll have Groove up a bit later tonight and most of tomorrow. Maybe some of us can find each other and fool around. My screen name is "Russ Lipton". Real original.

I'll be around as much as I can tomorrow, too. "Jonas Beckman" isn't too original, either.

RU could/should be able to hitch-hike one of five ways -

RU and Groove users exchanging interesting data (Stan's scenario) but no intense integration otherwise?

RU connecting up to Groove engines/components as an IDE for Groove component and tool development.

RU looking just like RU does now but using Groove services for augmentation and collaboration (security? relay servers? account management?).

RU looking just like RU does now but using Groove services as above and some Groove tool or UI components in lieu of RU components (Groove chat? voice?)

I like babies. Course, I have five of them. You'll notice five options above too. Just a coincidence.

Don't be so sure it'll be slow. First there has to be a scenario. I'd like to see if we can hook the Radio UserLand chat system into Groove. Let it do the distribution. Handle it on a chunk-basis, one line per roundtrip.

I was also thinking it might make sense to install Groove on one of our servers at Exodus so it could integrate with Manila on-site. We actually have some free hardware at Exodus right now.

Seriously, this sounds very interesting. From what I understand, the first difficult design issue for any Groove tool is what kind of delta-state it handles: one line of chat looks just right to keep it simple.

And having dedicated hardware could be necessary - it's hard to tell already, but the Groove servers seems pretty over-loaded right now.

BTW - if anyone wants to invite me to a Groove space, please send the GRV-file as a mail to "jonas.beckman@indra.se". I have had problems accepting invitations via instant messages.

I would appreciate the opportunity to use the elegance, power and flexibility of RU in a "groovy" fashion - within shared spaces

Yep yep yep.

Groove's #1 Selling Point IMO, which is also not coincidentally my view of "groovy" fashion: it's really easy/cheap to quickly get groups of people connected in a secure way to share and edit all sorts of information, and easy/cheap to have lotsa such groups.

Some of Groove's Current/Maybe Cureable/Maybe Not Bozonic Points:

[1] Re-invented wheels versus greater use of web standard tools. One word should suffice: browsers !

[2] Complexity of tool development, and need to go outside Groove to do it.

[3] Performance and bandwidth issues.

[4] Tied too tightly to Windows and COM.

Interestingly, the Frontier-Manila-RU-niverse already beats Groove in a number of implementation details and strategic decisions, and could, I think, fully trump Groove with a few small but strategic evolutions. Some points:

[1] Manila discussion groups are more powerful and flexible than Groove discussion groups. Plus, they're delivered to end-users via browsers versus special tools.

[2] Frontier and RU outlines and OPMLs are to Groove outlines and editing as K'nexx building toys are to baby blocks.

[3] Frontier-Manila-RU development is a straightforward programmer's dream, and is done within the soothing tools. Groove development, as far as I have sniffed, admittedly not far, hints of twisted complexity and non-soothing tools.

[4] Frontier-Manila-RU work-play with browsers really well. Groove doesn't.

[5] F-M-Ru work on Windows and Mac. Groove works on Windows.

[6] Groove does lots of heavy lifting in the encryption and replication realms. Frontier-Manila-RU doesn't.

[7] It's (theoretically at least-- we RU FAQ.opml folks bumped right into a major showstopper bug in this regard in Groove, and it's frozen us in our Groove tracks for that project) easy in Groove to have all sorts of documents whose editing is shared securely with specific sets of [nerdal and non-nerdal] people. The UI for this is simple and elegant. It's not so easy in Frontier-Manila-RU: the toolset involves editor's-only Manila sites, along with pictures, stories, gems, and OPMLs stored on such sites, and the RU Cloud. Many limitations.

[8] It's easy in Groove to quickly set up and manage lotsa different groups working on lotsa different projects. The UI for this is simple and elegant. Not easy in Frontier-Manila-RU.

There are many strategic minimalist solution paths to [7] and [8]. One possible path:

[a] (with pre-apologies for any squeaky-wheel irritations) Adoption of dreams along these lines (which takes care of who can read/who can write/who can kill or move a document)

[b] Availability of multiple membership-only sites on the flagship UL Manila sites (editthispage.com and weblogs.com)(editor's-only sites are good, but the UI can confuse non-nerdals)(multiple sites for multiple projects -- right now, the flagship Manila sites limit users to one per email name, and most folks don't have as many email names as we total lunatics)(a members-only Manila site mapping to a Groove workspace)

[c] Availability of multiple templates on the flagship Manila sites (a template in this regard mapping to a Groovy tool)(any page can use any template)

[d] Multiple HTML windows and complete menu substitution available within RU (the highly-customized RUs created via this route and RU tools mapping to a Groovy tool)

What about [6] Encryption and replication facilities ?? Oooh ! Oooh! My head hurts. Maybe this is the one best left to Groove.

I like this one a lot !!!!!

http://jim.roepcke.com/1293

Conceptually, Groove makes me tingle like only a few pieces of software have before it.

I wish I had happier things to say. I want to love this software, but it doesn't love my friends, family and colleagues.

Jim

What a great post.

Agree with you about Groove's primary selling point. Underlines why their own first objective must be to lock-down (small-scale) performance of IM, chat, account management et al before they move on to the grandiose stuff.

On some of your points about Groove itself, from what I've seen so far:

[1] Despite your one word, could you elaborate for dense ones like myself? I believe they view browsers as a useful case, especially for one-to-many publishing, but too restrictive to cover what we all "want" for editing and collaboration. Or, to put the question another way, would you want Groove and/or its UI subsumed into browsing metaphor or to incorporate it more thoroughly? If the latter, where/how?

[2] Agree. I can't help feeling that they ran out of time here and had to go public before ability to ready Groove-centered IDE. I could be wrong. Certainly, they are extremely aware of the need to make tool-building super-easy over time. A counter-case is that they believe that others will stitch a variety of IDE's into Groove over time and they are content to wait.

[3] Agree 100%. Jury out, though I would place my money on Ozzie to make the needed mid-course corrections.

[4] Disagree from the perspective of what was realistic/doable as they continued on with their work. Like Userland, Ozzie and his gang are extraordinarily pragmatic (that's a compliment). Java was an option but there was too much chaos. Linux wasn't big until, say, 12 months ago, long after they made the key commitment. They took their early risks (admittedly also pragmatic) on XML (ca. 1997) and, later, XML-RPC. Having been burned so badly on Notes UI, they separated Groove UI layer and designed away from everything in COM that is Windows-centric. Ozzie's history with Notes was to support just about everything (even 390s). Groove multi-platform and multi-device support are baked into the plan, I'm sure.

Just as a by-the-way, my gut feeling is that, in part, this early release of Groove has been intended to see what sticks when stuff is thrown against the wall. I don't think they would be entirely surprised if Groove proved a "killer" in a domain they had never conceived ... surprised, yes, but not amazed. So, they are waiting for "you" and all of us to tell them, as it were, what this is about. As well as where it fails.

Your points about RU/Userland are also very interesting. Hope to get to them later.

(A disclaimer: though I have done a bit of work for Groove which has to help my evaluation intuitively, this is entirely personal opinion throughout. I am not privy to confidential information. If/when that happens, I'll stop posting ;-).

would you want Groove and/or its UI subsumed into browsing metaphor or to incorporate it more thoroughly? If the latter, where/how?

I'd like Groove to be able to converse well with browsers, so it can easily output to them and input from them. I'd like browser fluency to to be just one more arrow in Groove's quiver, not a UI focus but a powerful input/output option.

Browser fluency is one of Frontier-Manila-RU-niverse's great strengths. That strength, and Groove's weakness in the area, indicate, I think, one important direction for early
FMRu<-->Groove hitchhiking.

they ... designed away from everything in COM that is Windows-centric.

That is good to hear. Best to skirt the ties that bind.

Stan

There are two major approaches to this that I can see; variations on the theme to follow.

1. Make RU do the stuff that it doesn't currently do that Groove does.
2. Reimplement Groove, but using more cross-platform tools.

Let's take these one at a time.

1. RU has a damned nice object database, scripting language, and deep support for TCP/IP. It has world-class outlining support and XML support. On Windows it plays nicely in the COM world and on Macintosh it plays nicely in the AppleEvents world. On Macintosh it has the additional, underutilized benefit of the MacBird runtime being baked in, and MacBird itself is completely open source, so not only does RU dovetail nicely with the browser world, but also with the traditional GUI world.

   What it seems to lack by way of comparison to Groove is mostly a transparent, secure, distributed persistence mechanism coupled with some kind of authentication/trust model. I'm wondering whether the on-the-wire security stuff couldn't be handled relatively straightforwardly by making a DLL out of Wei Dai's Crypto++ library, assuming a higher-level protocol for doing key management, hopefully as transparently as Groove does. The distributed persistence stuff might be built on top of Cornell's C-Ensemble code, which implements a data replication service based on reliable IP multicast. It would be an interesting exercise to see how RU's OODB might be combined with the data replication service to accomplish a fault-tolerant global store like Groove's, with the security coming from a good authentication protocol atop the Crypto++ stuff.

2. Reimplementing Groove. Hopefully Groove Networks are already looking at this, as it seems they've painted themselves into a rather nasty corner by being COM-based. However, the Mozilla project of course already ran into these same issues and appears to be on the road to resolving them. If I were going to reimplement Groove, here's what I'd be looking at:
   • Standalone XPCOM for all the COM-related stuff.
   • XPToolkit for all the GUI stuff.
   • e4graph for the database stuff.
   • C-Ensemble for the replication stuff.
   • Crypto++ for the security stuff.
   • SWIG for integrating languages that don't already have XPCOM interfaces. Better yet, find a way to use SWIG to generate XPCOM interfaces specifically.

   Starting from these points should result in a cross-platform Groove without sacrificing functionality. Obviously, there would still be tons of development involved and even more spit-polishing, but such an effort could result in a cross-platform Groove and validate the efforts of the Mozilla team to make Mozilla a collection of building blocks that can be assembled not only into a browser but into a variety of other kinds of Internet-aware software as well.