Tim Knip's Groovey Weblog

Let's continue the conversation.................

Suite75 / Tim's experiments

I think can describe them better then i can

Integration scenario's

Public Groovespaces

Not all groovespaces will have the need to be private and secure but do have the need for some form of control .

Re: Public Groovespaces

> Not all groovespaces will have the need to be private and secure but do have the need for

Re: Public Groovespaces

Does the collaboration become more dynamic and spontaneous, and afford "better" integration with blogspace if groove users can publish selected Groove services (i.e. components or data within Groove), as opposed to having it be an all-or-nothing decision?

Re: Public Groovespaces

> Does the collaboration become more dynamic and spontaneous, and afford "better" integration with blogspace if

> groove users can publish selected Groove services

In theory. In practice, it will be very hard for people to manage the public/private boundary on a per-item basis. Psychologically it's better -- I think -- to be in one place or the other. This raises questions about Michael Herman's notion that a space that has "matured" can simply float to the Net. Are you sure everything in that space should go? If not, how would you decide? You'll find yourself doing an item-by-item inventory, trying to see what is or is not appropriate. I'm sure this will be way too much overhead for almost everybody.

Re: Public Groovespaces

I don't think a all or nothing option for a space is the right direction although i can imagine that you want to autopublish the contents of one tool.

Re: Public Groovespaces

At the risk of getting into implementation details, which I'm generally not good at, what obvious UI actions are provided to the user at each level of granularity. For example, 2 extremes - 1) A button option to publish the contents of a shared space into blogspace, 2) ability to right click on a particular object (i.e. a single discussion entry, or a single file) and publich only that to blogspace. Of course, many shades of gray in between. Would this be overly complicated to the user? Or could it be done in such a way that employed UI actions that most users are already comfortable with?

genereally i think you should be able to specifically select the content you want to have published and the rights for publishing can be granted to a group of people (admins) within that space only if needed.

Re: Public Groovespaces

From an overall architecture perspective, I challenge everyone to think laterally and also include other center-based web collab solutions like Yahoogroups (e.g. http://groups.yahoo.com/group/decentralization/).

Cheers,

Michael.

> some form of control .

Right. And this becomes a hard UI challenge if the rule for publishing is anything other than all-or-none. The minute people have to think about managing the public/private boundary on a case-by-case basis, it becomes way too much decsion-making and micro-management.

Imagine if we ruminated in here for a while and then arrived at some kind of consensus. Publishing just the parts of the space approved for public viewing would be, in the end, as easily accomplished by cutting/pasting selected material to some other space or straight to a blog.

OTOH, we could make the whole space public for viewing, but writeable by invitation only. I think that is an important use case. However, the extra degree of formality we'd expect of ourselves if these were a public space would undoubtedly impede the spontaneity of collaboration.

Re: Public Groovespaces

>>you can tink of a groovespace that will have all, or allmost all it's content published on the internet for people to read but only the member in the related groovespace can edit this information collaborative.

Yes, sounds like EasyWeb, partly

(fyi, EasyWeb is something I built a while back Cabezal EasyWeb Publisher.url but which is now unmaintained; Groove Networks owns the codebase). EasyWeb was oriented around publishing "websites", so one central piece was a templating system which could move Groove content into HTML (or XML of various flavours). It also had a "hands-off" publishing model: you set up the publishing parameters, and thereafter everything you do in the Groove space is automatically published up to your webserver.

That model may not be ideal: I was having this exact conversation earlier (with people at www.uprizer.com), and the use cases for integration with their stuff (effectively a distributed webserver) seem to be more relevant if there's an explicit "Publish This" button. The type of process I'm imagining is a content-creation activity in Groove: people getting together to create or refine a "document" or video or presentation or whatever, then having an "off-ramp" which can take one or a few specific pieces of Content back out of the Groove shared space.

Re: Radio integration: "publishing" (collaborative authoring) is only a part of the story. Necessary but not sufficient :-)

...sounds like EasyWeb?

you can tink of a groovespace that will have all, or allmost all it's content published on the internet for people to read but only the member in the related groovespace can edit this information collaborative.

Collaborative content management for newssections of websites etc.

Just a simple example but one that could get many people within a company into trying Groove:

update the newssection of your companies website or any other need for collaborative content management.

research , rewrite, add , edit and discuss items togehter in a secure space and only publish selective information to website.

Publish Spacereports or questions to an intranet

More secure and companywide to quickly find answers and/or people for specific issues

Experiments thus far

- use of Blogger API to send/edit posts to blog (blogger/RU)

NewsClient

More history from my back pocket. NewsClient was written at Agora, then maintained by Cabezal for a while, and now back with Agora. It's an RSS newsreader, in Groove.

NewsClient and NavigateTogether

Should be reasonably straightforward. The bigger question is: who has the time/motivation to do it :-0)

Re: NewsClient and NavigateTogether

I guess the question would be: since the NewsClient seems to share componentry with, say, the Discussion tool, why wouldn't the framework just give you that capability "for free"?

Shared componentry

Most of the newsclient is really different from the discussion and other tools; the list-style UI is the native Groove dataviewer, but the rest of the UI is mostly IE browser embedded (and the nice Flash piece), and custom spaghetti-gluecode.

There's also a prototypical "comments..." feature inside the newsclient tool (unfortunately we never really finished it properly). The idea here was that comments marked "public" would be re-published to a "community server", and the community server would publish its commentary as RSS, which other people (in separate Groove spaces, or in other aggregators) could subscribe to... (!)

Re: NewsClient

It would be nice if the NewsClient didn't trigger the unread mark at the shared space level.

Once NewClient is installed, the shared space is effectively always in an "unread" state from that point on (assuming a reasonable flow of RSS ... a 1-2 or more per day).

Michael.

NewsClient tool.url

Functionality: everything you would expect from a simple aggregator. No more.

- connect from Groove Tool to Radio using SOAP

>> if there's a SOAP-handler available in Radio, i can connect to it from Groove

>> when Edge Services is released: Radio could have macro's, scripts etc. connecting to a Groove-space: harvesting subscriptions news etc.

General question for Jon

Jon, obviously the rest of us in this space are heavy Groove users. Do you use Groove intensely? If not, what do you see as barriers? Does it have anything to do with a perception (right or wrong) that Groove is a closed box?

Re: General question for Jon

> Jon, obviously the rest of us in this space are heavy Groove users. Do you use Groove intensely? If not,

"Activation threshold"

Good term.

Re: "Activation threshold" - actually a design flaw in the Onramp

Re: there's a social threshold to cross before you press it.

Re: "Activation threshold" - actually a design flaw in the Onramp

This is also the same issue with the 1:1 Chat in Groove - my MSN Instant Messenger really is "instantaneous"; Groove IM is not.

Re: MSN messinger is more instantaneous but less secure.

I would like to understand how Messenger is "less secure"?

Re: MSN messinger is more instantaneous but less secure.

As far as I know the data is not encrypted. Anyone with a packet sniffer can read the data because its in the clear.

Re: MSN messinger is more instantaneous but less secure.

Additionally the passthrough msn messinger servers can be set to keep logs. The logs are not incrypted. Conversations from these logs have been supined by the courts and have shown up in court cases.

Groove incryptes the message on the client and transmits incrypted messages to the passthrough servers so the logs are not as easy to record and thus less likely to be a piece of evidence in some legal battle.

ssd

please forgive my spelling deficiency

From a pure technology perspective, I understand why Groove is "more secure" but Groove has it's own requirements for relay caching of deltas, etc. where Messenger does not.

How/why should I worry about my Messenger conversations being intercepted?

Michael.

MSN messinger is more instantaneous but less secure. I switch to groove when the level of secrecy is great enough to sacrifice the loss of speed and emidicy. The security model is a significant part of what makes groove work for me. Only port 80 and incription on both sides. Groove is one of the only apps I never allow for the password to be rememberd because Now It is the place where I share my closest held secrets with different nodes of my network of influience.

I had to sometimes go to the cmos house and install it myself but now anytime I can have his ear and thus have more influence.

Radio is more broadcast reputation managment. If dave tells me I should pay attention to Jon I do or atleast give it more time than I would because I go to scripting.com becasue of the celibrity reputation of Dave and the way he hand out or mediates annamous online reputation of thought,.

ssd

IMHO, this is actually flaw in the Onramp (and to a lesser extent Groove Workspace) because the current design runs out-of-process (Outlook relative to Groove) and because an entire shared space needs to instantiated. It's horrible to use.

This is also the same issue with the 1:1 Chat in Groove - my MSN Instant Messenger really is "instantaneous"; Groove IM is not.

(but at Parallelspace, we're fixing both of these with a solution to be released real soon :-)

Cheers,

Michael.

Even if you're an Outlook user and the Groove onramp is installed, there's a social threshold to cross before you press it. ("Will people ignore this? Is everyone using Groove? Is this the right thing to do - my boss is on the copy list?" etc.)

I'm not an Outlook user - my main email has been Notes for years now, and I could really use an equivalent onramp button there - but even now with people inside Groove Networks I often start a conversation in email, rather than starting in a Groove space. If you're copied on an exploratory email, it's easy to "lurk". If you accept a Groove shared space invitation, you might get more context than you need.

So, although I think Groove's incredibly strong in positioning as "ten times better than email" (because it solves all the horrible things about decisionmaking-by-email), it will get a higher rate of traction where the OnRamp is a more "vertical" application. My ancient "CPC" pitch (http://www.cabezal.com/ppt/CPC.pdf) opens some of those application ideas. Recently I've been involved with a couple more: an Autonomy onramp which gets context (and people) into shared spaces when it's been identified as a "cluster" by their content analysis technology; a project-management onramp which gives you a new shared space to fix the problems which are making your milestone slip. Both of those are Web-triggered (click a hyperlink to get a new Groove shared space): the hyperlink is not the space, it's an option on the space (per dpr_ options.url ).

Q: Is there a "Radio OnRamp"? What should it be for?

Permeable public/private boundaries

You say "My conclusion is that Groove needs to find ways to make the public/private boundary more permeable... seems to go against the very bedrock principles on which shared spaces are built..."

a non-debate, imo

See Space defintions (andyswarbs -PopG2#3) where I begin to argue that Groove or whoever should just get on on and do it.

- I don't think you have much reason to worry about Groove's principles here. We have a few guiding principles in how you should look at permeating that boundary (for example, that participants in a shared space should always be aware if their actions will be visible beyond the boundary of that private shared space), but not about whether it's a good idea!

NNTP is almost the opposite case: so open that many public newsgroups suffered the "tragedy of the commons" with spam, but incredibly elegant in managing "multiple collaborative scopes" (your term, which I just read...!).

Some prior rambling of mine (again) - http://www.cabezal.com/ppt/soft_edges.pdf

Re: General question for Jon

Jon may appreciate this thought most.

mind of Dave / mind of Ray

You may well be right.

Where that leads us, I am not sure :-)

Radio and thus Frontier is somewhat of a self-portrait of the mind of Dave Whiner. Dave is the center of the node that broadcast to lots of people. I met Dave through Mason Hale who I think wrote the first cgi framework for frontier thus making it web enabled and allowing dave to reach and interact with a much wider community of like minded people. I always have trouble understanding frontier and radio because my mind is not like an object database. I have difficulty with the mental model or sense making exercise; in time I learn enough functionality to get my task done usually with help from Mason.

Now I have never met Ray Ozzie but I understand him deeply. Mostly because Groove is likewise a self-portrait of the mind of Ray and it makes sense to me. Groove is about sharing secrets. Most of the work Ray does with three people one being his brother. He and I are deeply private people but span the holes in our social network. I read scripting frequently and pass on things to other nodes in my network often using groove as the information transport.

I have installed more groove trial versions than anyone I know. I depend on the alert icons to see the horizon of my network.

If we can get ray and dave together in a social setting and watch how they integrate that is the way we should approach the integration of radio and groove.

Stephen Dulaney

> what do you see as barriers? Does it have anything to do with a perception (right or wrong) that Groove

> is a closed box?

No I don't use Groove intensively, but not because I don't want to. I would like to use it more, but in my day-to-day professional intercourse I do not find other Groove users with whom to collaborate. This may change now that I'm with InfoWorld, since folks there do use it (I'm told). We'll see.

This has been a longstanding concern for me. I first saw Groove in beta when Tim O'Reilly invited me along for a visit to the company, in (I guess) May of 2000. I loved it of course, but I was immediately worried when I saw how it was not connected to the primary mode of collaboration, email, and also only indirectly connected to the web.

Still, I considered whether to evangelize Groove in the same way that I had years earlier evangelized private NNTP collaboration (which was and remains incredibly powerful, although nobody much cares). In the end, having felt burned by the failure of my own Internet-style approach to catch fire, I decided to take a wait and see approach. So I waited to see who would send me an email with a Groove injector.

Despite the fact I was an author of the Groove chapter in the ORA P2P book, and elsewhere visibly writing about Groove, nobody ever invited me into any shared spaces. Nor has this changed (so far) with the availability of the 2.0 Outlook on-ramp.

If I had not specifically and publicly arranged to get myself invited into this space, it would not have happened.

My conclusion is that Groove needs to find ways to make the public/private boundary more permeable, and find even more aggressive ways to lower the activation threshold for transitioning into Groovespace. I completely appreciate how difficult this is, given that it seems to go against the very bedrock principles on which shared spaces are built -- the reasons for which I understand and agree with. (It was, after all, the security chapter of the P2P book which I helped to write.) The concept of a "public shared space" seems, on its face, to be utterly un-Groovelike.

I hope that we will all discover, over time, that this concept could make sense. And, that we can articulate more clearly how and why.

Technote: "E-Mail Discussion List and Groove Shared Space"

I've just joined this discussion and wanted to tgrow out a few things I've been thinking of ...before I get assimulated :-)

One parallel area of thinking I've been working on is how to motivate and gradually migrate a web/email based discussion group (e.g. a Yahoogroup in the technote's example) to a Groove-based solution. Checkout http://www.parallelspace.net/ddd/.

Weblogs aren't really significantly different except that they're 1:many. Caveat: Jon and Dave Winer just got me started using weblogs at the ORA Emerging Technology conference last month. Checkout: http://parallelspace.blogspot.com/.

Michael.

Why not create a Personal Publishing Server as a Groove tool?

Checkout http://parallelspace.blogspot.com/ where I begin to describe an HTTP Service Groove tool that allows you to selectively publish the contents of a shared space ...a discussion that I started in the Chat window for this tool but no one else was online to chat with. :-)

Re: Why not create a Personal Publishing Server as a Groove tool?

I was just thinking about this too I think...

Re: Why not create a Personal Publishing Server as a Groove tool?

A Groove Tool can check the RSS-feeds living in someone's copy of Radio (one condition: a RU-user has to install a Web Service making this possible. >> no big deal: just copy a txt-file to RU's Web Services folder).

Simple to get these items from RU...

So if one would accept Radio as 'backbone', all stuff described in this thread is possible with ease:

- publish stuff (opml, rss) from Groove to RU

- get stuff from RU into Groove

And... sure, all this can be done also using a Groove Tool as Personal Publishing Server, or dumb FTP, or use IIS Personal Webserver, or...

Re: Why not create a Personal Publishing Server as a Groove tool?

Another thought: Edge Services

a user makes a SOAP-call to some Groove-Tool to request some data...

Sounds like a WebServer to me... No need for another one?

What if we provided a way to leverage the invitation mechanism for subscribing to an RSS feed. So I could expose something like the discussion tool, in rss format (or opml) but unlike Radio, where I have no control over who is subscribing to it, I could get an IM when someone tries to do this, and then approve or disapprove them. I don't know... now that I write it down it doesn't seem that useful. But Matt's post about the asynchronous nature of Blogs got me thinking in this direction. Because Radio does have RSS subscriptions, so in essence you are notified when a Blog you are interested in changes.

I too have to learn more about Radio, since I really haven't had any time to play with it at all, other than the OOTB functions.

...kind of like EasyWeb but have the tool itself expose an HTTP Service ...perhaps like Radio (but I'm not familiar enough with Radio to really make this comment).

Michael.

Shared Space Chat Archive 020605 (Is this the same as a blog? ;-)

Tim Knip/Suite75: 6/5/02 10:48 AM

Re: Shared Space Chat Archive 020605 (Is this the same as a blog? ;-)

If the chat was archived in this way and then removed from the main chat area, should a link to this item have been left behind in the chat? Just curious, I'm not completely up on the protocol for this kind of thing, and was puzzled to see the chat had been truncated.

Re: Shared Space Chat Archive 020605 (Is this the same as a blog? ;-)

Good point Jon ...even from the perspective of simple etiquite. (I wonder when Groove will get a spell checker .... ;-)

I didn't know this chat archive above

Chat Archives (andyswarbs -PopG2#3)

yo!

Jeroen Bekkers/Suite75: 6/5/02 10:50 AM

yo

Tim Knip/Suite75: 6/5/02 10:48 AM

http://www.xmethods.com

Tim Knip/Suite75: 6/5/02 10:48 AM

check available webservices...

Jeroen Bekkers/Suite75: 6/5/02 10:51 AM

ok

Tim Knip/Suite75: 6/5/02 10:50 AM

hehe, kan ik nu allemaal gebruiken vanuit groove

Tim Knip/Suite75: 6/5/02 10:52 AM

maar goed... nu eerst een toepassing verzinnen...

Tim Knip/Suite75: 6/5/02 10:54 AM

maar tof hoor, google api: search, spelling-suggestion etc

Jeroen Bekkers/Suite75: 6/5/02 11:02 AM

just invited Jon Udell

Jeroen Bekkers/Suite75: 6/5/02 11:05 AM

just invited Hugh Pyle

Jeroen Bekkers/Suite75: 6/5/02 11:05 AM

Hi jon

Jon Udell: 6/5/02 11:04 AM

Hi Jeroen and Tim

Tim Knip/Suite75: 6/5/02 11:04 AM

hi Jon

Jeroen Bekkers/Suite75: 6/5/02 11:06 AM

hi, i thought let's open this space to discuss some integration scenario's

Jeroen Bekkers/Suite75: 6/5/02 11:07 AM

Tim has been doing some nice experiment to integrate Groove and Radio and we feel it's a powerfull combination

Tim Knip/Suite75: 6/5/02 11:05 AM

with upcoming Groove Edge Services, integration could be compelte...

Jon Udell: 6/5/02 11:06 AM

Can Tim's work be demonstrated here?

Tim Knip/Suite75: 6/5/02 11:06 AM

I have to make a tool first, hehe

Jeroen Bekkers/Suite75: 6/5/02 11:08 AM

hi Hugh

Jeroen Bekkers/Suite75: 6/5/02 11:08 AM

can you invite matt and John , i don't have their vcards

Hugh Pyle/Groove: 6/5/02 11:11 AM

Hi Jeroen - greetings from rainy England. (Dylan's happy, though - Ireland 1:1 against Germany!)

Tim Knip/Suite75: 6/5/02 11:07 AM

had to get to grips with SOAP, WDSL etc...

Hugh Pyle/Groove: 6/5/02 11:11 AM

Sure

Tim Knip/Suite75: 6/5/02 11:07 AM

hehe! last minute!

Hugh Pyle/Groove: 6/5/02 11:13 AM

Just catching up - back later

Hugh Pyle/Groove: 6/5/02 11:13 AM

I invited Matt and John

Jeroen Bekkers/Suite75: 6/5/02 11:11 AM

ok, thx,

Jeroen Bekkers/Suite75: 6/5/02 11:13 AM

Tim, can't we add an early version of the blogger tool ?

Jon Udell: 6/5/02 11:12 AM

I'd be very interested to see that.

Tim Knip/Suite75: 6/5/02 11:12 AM

sure, but it's not SOAP. Blogger Tool uses XML-RPC / Blogger API

Tim Knip/Suite75: 6/5/02 11:12 AM

blogger.com only...

Jon Udell: 6/5/02 11:13 AM

Why only blogger.com?

Tim Knip/Suite75: 6/5/02 11:13 AM

oops... description not found

Tim Knip/Suite75: 6/5/02 11:14 AM

it was start of exploration XMLRPC + SOAP

Tim Knip/Suite75: 6/5/02 11:14 AM

after succeeding using blogger.api started checking out SOAP

Matt Pope/Groove: 6/5/02 11:20 AM

Hello all

Jon Udell: 6/5/02 11:16 AM

FWIW, XML-RPC and blogger API are the most prevalent integration path in blogspace today. I regard the transition from that to SOAP as a relative non-issue. The big issue, to me, is how to construct a user experience that makes sense for conversations flowing between the two worlds.

Tim Knip/Suite75: 6/5/02 11:16 AM

Hi Matt.

Tim Knip/Suite75: 6/5/02 11:17 AM

y, Jon, I agree: I now have the knowledge to create an experience. Question is: what experience

Jeroen Bekkers/Suite75: 6/5/02 11:19 AM

hi matt

Matt Pope/Groove: 6/5/02 11:23 AM

Hey Jeroen. IMO, the experience needs to be seamless. Jon is correct in that we don't need edge services or any other hooks now to test the concept. But we do need a more seamless transition for the experience to pass some threshold of usability. There need to be on-ramps and off-ramps in between Groove and any other application or system, Radio or otherwise.

Matt Pope/Groove: 6/5/02 11:24 AM

I'm going to invite John Burkhardt to this space.

Jon Udell: 6/5/02 11:21 AM

What experience: exactly. I know there have been some use cases articulated already. Probably by one of you guys. Can those be captured here as a point of reference?

Tim Knip/Suite75: 6/5/02 11:22 AM

The Blogger Tool (new version) connects to blogger.com or RU just to send posts to the blog. Posts can be edited etc.

Matt Pope/Groove: 6/5/02 11:34 AM

The experience I was referring to in my post is the following (again, just one example): 1) Many people are operating in blogspace, making posts, perusing eachothers, but limited by time in the extent to which they can become engaged in all that they may find interesting, 2) Somebody makes a post that merits a more intimate and dynamic conversation than can be accounted for in an I-post-you-post sort of way (admittedly participants may not realize this until they've already been through a few I-post-you-post cycles), 3) The dialog gets brought into groovespace - via a seamless on-ramp - where contextual tools and new participants can be added readily, 4) when the discussion/collaboration ends, or through intermittent updates from a persistent discussion, participants post information/results back into blogspace - via an off-ramp - from the Groove shared space for a wider audience to consume. Further, linking and syncing with public groovespaces from weblogs would make the integration even tighter.

Matt Pope/Groove: 6/5/02 11:34 AM

again, that was just one "experience" example

Tim Knip/Suite75: 6/5/02 11:33 AM

the off-ramp is easy, wondering how to do the on-ramp...guess this could be done by some invitation-link?

Jon Udell: 6/5/02 11:34 AM

Matt: I think this is perhaps the central use case. Lots of questions to resolve. For example, does "dialog gets brought into groovespace" mean importing a structure of links, or fully replicating the content. In either case, how are the boundaries of the dialog defined?

Matt Pope/Groove: 6/5/02 11:38 AM

True, you've done the off-ramp. We've done other forms of on-ramps. For instance, we have an Outlook on-ramp that allows a user to rather easily move an email thread into a new Groove space and simultaneously invite the email thread participants to that space. Same concept should apply here.

Matt Pope/Groove: 6/5/02 11:41 AM

Jon, those are great questions. I don't have a readied answer, but I think the Outlook on-ramp example provides some insight. Having said that, it is different within blogspace because of the fact that there is no single "place" to import stuff from; there may be a 5-way blogspace dialogue - how do we pull the relevant info from each place? And how do we determine what is relevant? Good questions

Jon Udell: 6/5/02 11:43 AM

Matt: Agreed. The answer is emerging, I suspect. We see blogs beginning to be conscious of, and to encode, their relationships to other blogs. I'm sure this will continue because people are finally seeing it is in their own self-interest to be more formally self-descriptive.

Tim Knip/Suite75: 6/5/02 11:43 AM

let the Google API make a search? check the urls's you want into that space. Hmmm, the url's must be accessible via Blogger API... just thinking aload

Matt Pope/Groove: 6/5/02 11:52 AM

All, I need to check out of here to go prepare for a meeting this afternoon. BUT, I would love to see this conversation persist over time. I will check back later to add further thougts and comments. Jeroen, thanks for creating this space!

Jeroen Bekkers/Suite75: 6/5/02 11:51 AM

ok, see you later, just invite other interested people..

Jeroen Bekkers/Suite75: 6/5/02 11:56 AM

I think for any tool or integration scenario it's important that people still feel the Grovespace is a secure environment, having a all or nothing button can make people a bit hesitant in expressing their thoughts in the Groovespace thinking that any moment all contents can be published. i can think of some explicit non-to-be-published area's within a space/scenario

Jeroen Bekkers/Suite75: 6/5/02 11:59 AM

but again many scenario's possible from simple collaborative blogging (for a conference etc) or in a bigger framework like Rendeszvoo.net with a more open and fluid interaction between spaces of different intrest

Jon Udell: 6/5/02 12:06 PM

Like Matt, I have to run. But will check back. Thanks for inviting me here!

Jeroen Bekkers/Suite75: 6/5/02 12:10 PM

ok, later :-)

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:14 PM

Hi John

Jeroen Bekkers/Suite75: 6/5/02 1:22 PM

hi michael

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:21 PM

Hi Jeroen

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:22 PM

I was just looking for some information on a Asynch Pluggable Protocol (app) handler I wrote called "ddtp:"

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:23 PM

It enable web developers write plain own HTML web page based web sites and host them in an offline Outlook/Exchange public folder

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:23 PM

e.g. ddtp://localhost/ddtproot/default.htm

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:24 PM

in your browser would render the HTML content, MS Word docs, etc.

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:24 PM

There's no reason why the same could be written for Groove (with EasyWeb as a base).

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:25 PM

...or for that matter, write an HTTP server that runs as a local Groove tool

Michael Herman (Parallelspace V2#3)/Parallelspace Corporation: 6/5/02 1:28 PM

...continued in http://parallelspace.blogspot.com/

"Human router"

Radio is neat for several reasons (and every day, it seems, Dave invents more). I've spent a while trying to abstract the real nuggets in there, and there are loads. But I think a key one is this: the Radio web is a peer-to-peer information network, where the routers are humans. Radio's subscription, aggregation and publishing functions are subservient to the routing function.

Radio integration suggestion

How about: publish the contents of all your Groove spaces as RSS feeds?

Rendezvoo and RSS

fwiw: Rendezvoo published the list of spaces (not the contents of spaces) as RSS feeds. Then, multiple rendezvoo servers syndicate their space-lists amongst each other, creating a cross-linked topic network.

Re: Rendezvoo and RSS

What is Rendezvoo?

Re: Rendezvoo and RSS

Rendezvoo.net (not active at this moment).url

I built rendezvoo at a previous company a long while ago. It's out of action, hopefully temporarily - we built it as a custom transceiver, but it really needs to be ported as a "startup bot" on the Groove Enterprise Integration Server.

The model is:

- A "rendezvoo site" has { a Groove identity; a Web page listing the spaces of which this identity is a member }

- If you invite a rendezvoo site identity into your shared space, it publishes an invitation on its Web page

- When a predetermined number of members are in the space (or various other criteria), the invitation disappears off the web page

- multiple rendezvoo sites can be syndicated (in an arbitrary network); each site then looks like part of a Yahoo-style structure, listing its "child" sites and "parent" site(s). By "subscribing" to each others' lists of spaces (the list of spaces is published as an RSS feed...), sites maintain an index of all the spaces on the network (so you can search for spaces by description, by metadata, etc etc). And of course, since the feed is RSS, you can use Radio or other aggregators to subscribe to sites which particularly interest you (so you get sight of new spaces being posted to the rendezvoo network).

BTW as noted in my InfoWorld review of Groove 2.0, the enterprise integration does give you visibility into the spaces used by your managed identities, and also the tools used there. These info could certainly be propagated to promote awareness and facilitate routing.

- Jon

Re: Radio integration suggestion

The tool Tim is working on at this moment can be described as a Groove Feed generator , all kinds of data can be exported from a groove space using RSS, OPML etc. lot's of scenratio's how to use this feeds, to subscribe to or to use as the content in a webtemplate.

Some more details on Suite75's Feed generator tool for Groove 2.0

We have been working on this between our other projects for the last 1,5 month and it's functionality has become more clear in the last weeks. Tim has planned to release a rough beta version next week.

Re: Some more details on Suite75's Feed generator tool for Groove 2.0

How do you actually get at the data inside of a tool? If you want to "publish" a discussion tool, what level of abstraction does the publisher work with? Records? Or the beta Discussion API?

Re: Some more details on Suite75's Feed generator tool for Groove 2.0

records...

OT - Groove tool development

So this is something that will most likely break in the future. I'm not sure how this is presented to Groove developers. In other words, I've never looked at Groove development from the outside in. I know how tools are written internally, and I know more than I care too about how they evolved ;) Right now there is a lot of dicsussion about how to publish public interfaces for a tool. The thinking is that RecordSetEngine is an implementation detail that code external to a tool shouldn't know about. You can get it if you know the component url. But you can't count on it being there for subsquent versions of a tool. Now, there is also discussion about when a tool's version needs to change, or its name, etc. But the point is, you install Groove 3.0 and now the "DiscussionTool" isn't based on records anymore but something else (hypothetically speaking of course).

got details from the discussion TPL

I'm wondering primarily because Discussion is one of the two first tools that Edge Services will use, yet the API that I'm using to get at discussion entries is not published yet.

When the tool will be installed in a space you can set it up to generate a couple of XML based feeds from the content of different Groovetools. Like the outliner and discussiontool. You can choose to autopublish the complete contents of one tool , for example outliner to OPML, (blogrolls, brainstorming etc) or you can select the different items you want to publish from a iscussion tool by marking them in the tool. There also will be a simple texteditor in the tool to post items directly, this texteditor is realtime (like Groove txt tool) and can be used to do some collabarative blogging (simular to the Rotterdam Blogging tool)

Initially the generated feeds will be RSS and OPML that can be exported in 3 ways.

-to a Blogger.com weblog,

-to a properly setup Radio environment

-to any other location using plain FTP (intranet, internet, extranet etc)

- then, if you're using Radio (or another RSS aggregator) as a "dashboard", you can pick up Groove content and route it...

(this opens the question of visibility-without-awareness, of course)

Another integration suggestion

"Blog this" as a function on the transceiver (eg. on the Groove top-level menu), to pick a single item inside Groove (discussion, primarily) and publish it to your weblog. Perhaps also publish an invitation to the shared space it came from.

A Groove to Blog OnRamp? :-)

Re: Another integration suggestion

Yep, Tim also built this a kind of functionality as a prototype, just check the discussionitem you want to have published and hit "post"

Does this runs against a modified version of the Discussion tool? ...one that has the Post button?

nope, but it's an idea

tool scans space for discussiontool, lists items in ListView with checkboxes

Re: "Human router"

That is exactly the terminology I came up with in my first article on Radio: http://www.byte.com/documents/s=2473/byt1012422475646/0204_udell.html.

Re: "Human router"

I just joined one of Andy Swarbs spaces of spaces. Its an interesting idea. Imagine that a blog is a human router for web content. This is a human router for Groove spaces. If you haven't been there, its basically a files tool with a bunch of .grv files in it. And he has an outliner in there too with links to each space, and some categorization.

Extract summary information from Groove spaces...

This is exactly what we want to do with corporate portals: have your personal portal page show a summary of new, interesting or relevant information from your shared spaces. Right now that's achievable by having a tool in Groove (or function in the transceiver) export that information to a portal's metadata store. Edge Services provides a way to have the portal query that information realtime, using SOAP.

Re: "Human router"

> But I have to dive in. This gets back to your other point of the weakness of Groove being that you have to have everything on your

Re: "Human router"

We discussed this also during the rotterdam conference (with Michael and Hugh i believe it was) Space metadata, contexting or space summaries would be very usefull, if not vital, to connect people and ideas within a company .or community. I feel this should be build in Groove as a standard option so the space manager can choose to activate it and maintain, But if not it should be quite easy to for a experineced Groove developer to make a simple template tool to add to a space that can be used to compose this metadata and publish it by a RSS feed to a space portal on the internet or a companies intranet. again this task seems more logical for Groove to develop then for a third partydeveloper but it can be accomplished and on a short term if needed.

Re: "Human router"

One of the concepts I've embraced with the Edge Services APIs fits this really well. I decided that every data object should provide a "descriptor" version and a full version. For example, getting a file descriptor gives you the name, size, date, etc. but not the bytes. Getting a discussion item "descriptor" gives you the author, subject, date but not the body. I had considered this useful when I was thinking about small devices - but in this context we are talking about it makes a lot of sense too.

Re: "Human router"

Can you generalize this so that I can issue something like a WebDAV query where I can retrieve any set of attributes and elements from the schema?

Queries

Yup... I'm all over it. Tomorrow though.. not today. We'll get there.

Don't let Edge Services 1.0 be an ad-hoc architecture and design

You need to think enough about the general functionality you need to provide today so that you can get the architecture right and the APIs almost right today.

Re: Don't let Edge Services 1.0 be an ad-hoc architecture and design

I totally agree with this.

The road map is to release a "preview" mode of the system in a few months. This is not considered 1.0. Its considered alpha or something. There was a large boot strap process just getting any functionality at all and implementing XPath is non-trivial. I agree that consistency is a goal from the outside in, but its not a matter of reusing our existing implementation.

There are always trade-offs with releasing any new system. I have to weigh the cost of designing the uber-architecture that will be robust enough for all time and space vs. getting something out there that people can start using. We decided to cut this feature for the preview release so that we could give people something to play with sooner.

For example, Edge Services 1.0 needs to provide a XML-based query API (something like XPath or XML Query) so that I as a developer can start from day 1 using the right API (which can evolve a little bit over time).

However, in your V1 implementation of that API, you can limit the range of query syntax that you initially support (similar to, for example, the current limitations in the XPath query support in DVCs). In fact, Groove Networks should be using one XML query technology for DVCs and Edge Services, etc. with identical query APIs and XPath query implementations. There's no reason for them to be different.

Don't let Edge Services 1.0 be an ad-hoc architecture and design.

Cheers,

Michael.

Don't limit me, as a developer, to subset A or subset B.

Michael.

> machine. So it makes the process of joining a space a heavy weight process. IT could be a completely different experience if coming

> and going was easier.

Very interesting point. This goes back to one of my never-ending theme, "heads, decks, and leads" (,http://radio.weblogs.com/0100887/2002/03/08.html#a121). It's a universal principle. Every information system, including a Groove space, benefits from an info architecture that layers the content, such that some minimal top layer (like titles) can be scraped off, and used externally as a teaser. Yes, joining a Groove space is a heavyweight process. But even a click on a web page is expensive. Anything that disrupts your current context is expensive. So you always want some clue, in your current context, as to whether that next click (or that next shared space) is going to be worth your while. You want a digest, a summary, that you can scan. Groove spaces ought to be prepared to export such summaries.

PS: While I was typing this, Hugh made the same point :-)

Of course, I always want more. I imagined his space has kind of a hub. But in that hub I want to see where all the other links will take me. I'd like to see, for example, the member list, or the list of tools, or the most recent post. But I have to dive in. This gets back to your other point of the weakness of Groove being that you have to have everything on your machine. So it makes the process of joining a space a heavy weight process. IT could be a completely different experience if coming and going was easier.

With Edge Services, it would be possible (and I think this might be what Dave would call a "Mind Bomb") to write a tool that could extract information from other spaces. So I could write a space aggregator tool, that could pull information about other members' spaces and displayed them in a hub space like Andys. We could use this to in essence, publish what else we are doing in groovespace.

I agree that the routing is the core function, and publishing/aggregating are subservient.

How, in your view, can/should that routing function map into Groove?

- Jon

That sounds kinda like "gnutella search by carrier pigeon" - the latency of transmission is measured in hours, if not days.

But in practice it's really powerful, because the routers are "tuned" (in really human ways): we pick up and forward things which resonate. Not by creating (say) RDF-encoded tables of "who knows what" and "who knows who" (http://www.knetus.net/white/knowledge-flow.html) but by cross-linking the knowledge network in ad-hoc ways.

"K-logs"

John Robb (http://jrobb.userland.com) coined the "K-logging" phrase, and I've been quite sceptical: it just looks like an attempt to sell Radio to enterprises, without much quantifying information on how that would add value.

Re: "K-logs"

From enterprise customer perspective, are they more likely to want to integrate with their exist environment of intranet web sites, Exchange public folders and/or Lotus discussion databases, internal email discussion lists, eRoom-type collab portals, etc. vs. being interested in adopting another collab vehicle like Radio?

Agree

There's lots of widely-deployed corporate infrastructure out there, and it's pretty varied, and it's not Radio.

But Radio and the network of weblogs does show some very interesting social dynamics, which I believe have relevance to enterprise KM...

I'm just trying to be pragmatic here as far as the real world of enterprise customers is concerned.

Michael.

But this also is a sweet-spot for Groove/Radio integration: Radio weblogs as an off-ramp for stuff which is happening in Groove shared spaces. This works because it sidesteps the visibility issue: internal weblogs are inside the enterprise firewall perimeter, so visibility is handled by the network infrastructure rather than by the software (this may be a Bad Thing in principle, but it's reality).

HTTP and local webservers

Is this a viable infrastructure?

Re: HTTP and local webservers

Re: [Are HTTP and local web servers] a viable infrastructure?

Re: HTTP and local webservers

Yes, they're one next-level stack. SSTP is another, different, symmetrical stack. DNS is another discussion altogether, though.

HTTP is ubiquitous. It works. But it also breaks, in exactly the circumstances where Groove excels: secure "location-independence" (eg. this laptop of mine, which never had a static IP address and likely never will, but can be a peer, listening for incoming connections on the SSTP ports).

How many webloggers run their own HTTP server locally as the main host of their weblog? Very few, I'd guess. Radio's upstreaming is one approach to fixing the addressability issue. Groove's edge services "SOAP router" (non-caching) is another. Yet another might be to have a cacheing reverse proxy, together with dyndns, to fix my IP address to "hughsweblog.this.net" and reverse-proxy that to my laptop if I'm accessible from the public net.

These are the very next levels in the communication stack above TCP/IP and DNS, n'est pas?

Michael.

(I think Groove's "edge services" infrastructure of local SOAP-servers, plus cross-firewall SOAP router to handle the usual case where those endpoints don't have static IP addresses, is more general and more useful. This is a different approach to Radio, which solves the disconnected-peer issue by upstreaming content to hosted webservers)

What is the definition of the problem we're trying to solve?

We've shared our top-of-mind thoughts (which is good and important) ...but what is it that we're trying to solve?

For me, it's more open-ended than that

I could sit down write some code to hook stuff together. But I really don't want to spend any time doing that (unless it's immediately useful); I'm more interested in figuring out what would be a really "concise but interesting" sort of integration.

Re: What is the definition of the problem we're trying to solve?

There's more at stake than 2-way unfettered interop among various collaborative tools. I've done a boatload of that over the years. Have done NNTP to Web, email to Web, all the combinations. Making Groove a peer of these others is not, in itself, interesting to me, or a solution to anything.

Re: What is the definition of the problem we're trying to solve?

Great list Jon. This touches a point I made to Jon Robb a couple months ago in one of my first posts. He had made a relative comparison between Radio-Groove, implying that it was a one-or-the-other option. My point was that they are very different, and actually quite complimentary and that ideally, they would work together seamlessly. Think about what happens in the non-computing (i.e. "real"), contextually physical environment: I just got out of an 80 person meeting, which consisted of 2 people presenting to 78. In the middle of that meeting, I leaned over to the person next to me and we had a related sidebar conversation, then we turned our attention back to the presenter. Then the meeting ended and as I walked away I had another related conversation with a developer, which morphed into a slightly larger conversation when we brought another product manager into the dialog. And so on. All of these transitions happened without me actually taking note of them. There were no apparent barriers, I didn't think about the transitions as they happened, they just happened organically.

As I see it, I could transpose this scenario into the virtual world (i.e. the computing world). My motivation, the reason I started this dialog in the first place is that I see an opportunity for Radio and Groove to integrate in such a way that we can remove the shim that is technology - and all the barriers to natural interaction that it imparts - from the domain of online comms, such that we no longer feel unnatural transitions. Is that what we all want; an online world that is as easy to communicate within and move between parallel contexts within as the "real" world? I'm not even sure it's possible, but it's not a bad target.

To me the problem to solve is: can the different strengths of these different modes complement one another?

Strengths of Groove:

- context assembly (all the parts kept together)

- well-defined groups

- private/secure

- space is truly shared, interaction is direct

Drawbacks of Groove:

- don't always need all the parts here on my disk, the web's approach (pointers) is often easier/better

- don't always need well-defined groups, the web's fluidity and loose affiliation can be easier/better

- don't always need private/secure, can work against the "horizon of observability" effect

- don't always need shared-space direct interaction, weblogs that federate but are individually controlled

are a different and useful model

Strengths of Weblogs:

pretty much the inverse of above

Drawbacks of Weblogs:

pretty much the inverse of above

I think the first thing to solve is for everybody to get clear that both of these modes are valid, and to understand in which circumstances to use one or the other, and how (and why) to transition between them.

Jeroen's public link to this space is essentially the QuickTopic (http://www.quicktopic.com/) (formerly TakeItOffline) strategy. A simple, natural way to connect the two worlds. What we are doing here is more informal and immediate than if we were writing for our weblogs -- "for publication" so to speak. And yet, Jeroen has extended the horizon of observability by pointing to the space. If at some point collaboration here needed to "Take It Offline" still further, a subgroup could decide to move into another space into which the public would not be invited.

I think, basically, that more people need to experience these modes and transitions, using the existing/available tools, before anybody goes too far down the road of building anything. And hopefully by the time there is more awareness on both sides -- bloggers of Groove, Groovers of blogs -- things like edge services will allow rapid and iterative development of whatever glue is needed, in a bootstrapping mode that can be used, and reacted to, in an immediate and interactive way.

What's the definition of the problem we're trying to solve?

Here's a couple ideas:

1a. Two-way unfettered interop between a variety of two-way collabortion tools including potentially all or some of:

web collab sites

Groove

SMTP listservs

NNTP news groups

1b. Additional outboard integration of one or more of the above to one or more "one-way" publishing environments:

blogs

conventional web sites

archives (email, web or shared space based)

more email :-(

Cheers,

Michael.

Activation threshold & the experience

Lots of good discussion happening in here. Hugh has thrown out some intriguing concepts, e.g. Groove data as RSS feeds, etc. But what really caught my eye was Jon's "activation threshold". So let me go one step further in suggesting a level of Radio/Groove integration that would impart a more seamless user experience by minimizing the activation threshold, I think. Let's forget about the semantics and the UI of the Groove "transceiver", and "accounts", and "telespaces", and "tools". What if there was no need for a literal transition from the Radio environment to the Groove environment, but under the covers that was exactly what was happening? With edge services, this should be possible. The scenario would go like this:

Re: Activation threshold & the experience

Neat idea. (Are you sure we don't want to drag people into the Groove UI, Matt?!)

Re: Activation threshold & the experience

Well we'd prefer there be a transition to the Groove UI perhaps. But we should always be mindful of enabling a comfortable user experience. As you know Hugh, we have a handful of ISVs talking about building Groove-powered collaboration apps, but with their UI. When edge services is ready for prime time, we'll be urging them to use it for their implementation. This Radio idea would be no different. Further, whether we advocate it or not, people WILL, I think, do this sort of thing with edge services. We're providing them with the "open" framework; it won't take them long to uncover all of it's possibilities. In fact, we'll help them uncover them with sample client code in the edge services developer kit.

Re: Activation threshold & the experience

I was thinking more about your question Hugh. It's important to note that there will be user limitations when you place Groove-powered contextual collaboration in another app/UI, i.e. other than the transceiver. There are reasons whey the transceiver is a rich client environment, e.g. persistence, online/offline, etc. Some of that will be lost in other environments. So I don't necessarily see the type of integration that I suggested as a replacement for the transceiver, but rather as an advanced on-ramp to the transceiver. If you place groove-powered collaboration within the Radio UI, there may be instances where the communication merits persistence over time and some level of richness that can only be rendered in Groove's native UI. That's when the thread gets moved to the transceiver.

The first piece of this is achievable today: click Discuss, launch a new shared space, or join one if there's an existing discussion on this topic. If anyone here wants some code to implement that, let me know.

The new piece with edge services would be to have the discussion happen right in Radio (or even a Web UI) without launching into Groove and context-switching the user experience.

Re: Activation threshold & the experience

Yep very interesting idea, this would at least solve some of the issues concerning collaboration with Mac users

I read a post on Hugh's blog that I find fascinating. I want to engage him in a dialog

Instead of clicking "comments", I click Discuss (or something like that, I don't know what the most appropriate term is)

When I do this, Groove instantiates a shared space between Hugh and I, under the covers

Now, in the browser-based Radio UI (either directly or in a pop-up), there is real-time contextual collaboration happening between Hugh and I

We both see the same thing within our respective blog interfaces - chat and/or discussion and any other tools (e.g. files) we want to add. So now, we actually have a "shared space", in generic terms not Groove terms, within our blogs. And we can invite other people

And then we can publish, or not, the contents (all or selected portions) of the "shared space" activity to our weblog

In essence, I'm talking about replacing the "comments" capability with something far more dynamic and synchronous and contextually rich. A nice benefit is that I no longer have to return to your weblog (your space) to see if you've responded to my comment; fundamentally, we share the dialogic space. The way it works is that Radio talks to the Groove client (running behind the scenes) via edge services. Groove provides the network and tool infrastucture that brokers the real-time peer-to-peer network, but it's all manifested within the Radio UI.

Basic onramp to this space from my weblog

I posted the link to this invitation file on my weblog: http://radio.weblogs.com/0104207/

Re: Basic onramp to this space from my weblog

I saw that. It's fascinating...the public/private membrane already is more permeable than I realized!

Re: Basic onramp to this space from my weblog

The way i did it is not very elegant, lots of room for improvement ;-)

Re: Basic onramp to this space from my weblog

The point is, you *did* it. We tend to take the simplest things for granted, and miss the obvious. I have been using Groove since pre-1.0, and yet I didn't know (or maybe forgot) that a Groove space could be opened to the world by simply blogging the invitation. If I didn't know that, think how many other people didn't either.

It's quite possible that the vast majority of the people who will read our blog entries today have never seen a live .GRV link that invited them into some discussion they might want to join.

- Jon

Re: Basic onramp to this space from my weblog

The invitation-link will work by just clicking the link if:

Re: Basic onramp to this space from my weblog

Interesting. This means that the static server at Userland, which is Apache on Windows (was Apache/Linux before the hack), contains that MIME type by default? Seems improbable, but...

Re: Basic onramp to this space from my weblog

No - just checked - the static Userland server doesn't have the MIME installed...

Must ftp the GRV to some other server...

Would be nice though to have the MIME on Radio-server.... Can we ask Dave?

You can also use a simple ASP page to set the MIME type if your web server/ISP doesn't support it ...

For example, foo.grv becomes foo.asp with the addition of the first line of ASP code at the top of your grv file:

[Macro error: Can't find a sub-table named "Response".]

1) the invitation (GRV) is placed on a server supporting MIME-type: application/vnd.groove-injector

2) clicker uses IE

I knew of course that invitations can be emailed, but did not follow through to conclude that they can be blogged, but of course they can.

Re: Basic onramp to this space from my weblog

Ok, the only danger here is that there is a major issue we haven't dealt with yet in groove, which is how to deal with giving your contact information to random people. For example, I might not want anyone in the world to get my vcard - but now they can! We have a spec for implenting a way to essentially revoke your vcard from someone, or block them from contacting you. But its a ways off.

Re: Basic onramp to this space from my weblog

> I should delete this space and be re-invited as another identity.

Re: Basic onramp to this space from my weblog

Yep, i considered this too and i can imagine this will keep some people out of this discussion because they don't want to expose their Vcards. But this issue will appear in any larger space. i think this issue should be adressed within Groove similar to ICQ with something like "Ignore user"

When you make the invitationfile for a space you can choose for a confirmation to be send or not. I choose not to have a acceptation required for this space mainly because i didn't want to discuss everybody's admission within the members of this space this would distract too much from the real conversation that takes place in this space and i won't allways be there to grant the invitation.

My experience is that my Groovecontact has never been abused untill this moment but i can imagine that somebody will be very hesitant exposing their Vcards in a public space so i would urge everybody who feels this way to start a new account to take part in this discussion .

...that's assuming someone hasn't already selected the entire member list, right-clicked and selected Add to My Contacts ;-)

Understood. Good point.

So, yes, its relatively easy to cross the boundary, but one has to be aware of the considerations. You can also, of course, allow someone to inject the .grv, but still require confirmation when they want to join. So there is some control going in. But you have to create the invitation that way - or maybe the space - I can't remember!

Having said this, I should delete this space and be re-invited as another identity. Or maybe just suffer any consequences to eat my own dog food!!

to make it easier for people to join this discussion, i guess this means this space is a public space so be aware of this in exposing your thoughts. ;-)

The news tool is very cool

I like it!

Re: The news tool is very cool

So I found a link in one of the blogs, tried to click on it and got the .grv in the browser as XML. I wonder why the Groove IE control isn't handling this properly?

Re: The news tool is very cool

I also am seeing GRVs show up in browser as XML. It seems that something has told the system to process GRVs as XML info rather than as a Groove file type when you click on it in the browser. When you click on it in the files system the right stuff happens.

The idea that a group could collectively maintain a list of subscriptions is really neat. I might not ever find all the ones that I like, but if I have a group of people with shared interests, or a space with a specific focus, other members can contribute to news feed sources.

And it is weird to see Matt Pope and Jeroen's blogs in there... kind of a circular reference... wait... is the link back to this space in there too!! Woah.

Use Case Scenerios

Here are some ideas I had on use cases from the Groove to Radio scenario ...

Re: Use Case Scenerios

Yes, I just came to a similar thought. "Blog this" meaning: publish this thing (which I'm writing) to my personal weblog.

Re: Use Case Scenerios

Additionally, in the case of collaborative editing and posting to a shared-space level blog, one could envision Groove providing a portal into a rich "collaborative" content management environment.

This, of course, would likely extend the scope beyond simply Radio blogs but into intranet/extranet/internet site content posting, editing, and archival as well.

That's a naturally good thing

- the document/item/article could embed itself a link to the "public" version, so everyone in the space can see it's weblogged

As a member of a shared space, I would like to be able to selectively publish any content, that I author and deem appropriate, to my personal blog. I think this option should be provided from within all tools and the resulting output should be structured to ensure it is displayed properly from within my blog, leveraging its design and layout containts. In this manner, I, as a member of a project team, can not only contribute something to the shared space but also have that content replicated onto my blog for broader public consumtions. Items like project status reports, significant research, code samples, and project milestones/timelines come to mind. At the risk of getting into implementation, I would expect, as a user, that simply checkbox ("Publish to Blog") would be all the UI assistance I would need. Subsequent edits of content via Groove should be reflected as edits to the original post in my blog. In support of this, I would expect to be able to define my blog at a Groove account level.

In conjunction, for components / content developed collaboratively with others, I would expect that finalized versions could be similarly posted to a predefined blog. In this case, I can imagine scenarios where an associated workflow would trigger the post at some configurable time(s) or some "authoritative" user would manually trigger the post, similar to first case. In support of this, I would expect to be able to define a blog at the shared space level.

Mark Pilgrim has done considerable experimentation recently on the idea of mining of a blog's referrers logs, to the point where he is able to display within the context of an individual posting, who has linked to it. I would expect that a similar feedback mechanism would be needed within the context of "published" content. In this manner, I would like to some type of back and forth between the two spaces.

Pluggable protocol handlers... (Michael...)

Michael wrote in the Chat Archive 020605 about "asynch pluggable protocol handlers". Anyone have some simple sample code? The registry-only version (associating a protocol with an app) would work for me, I think:

I have it

Done the registry thang, and a wscript launcher... gets you into Groove from the hyperlink nicely. Now to make that work "properly"... if it's any relevance here, I'll post some samples.

yeah!

It works.

Here...

on my skunkworks page,

http://www.cabezal.com/skunkworks/GrooveLauncher.html

http://www.cabezal.com/blog/2002_06_01_archive.html#77481678

Not publishable, yet, but I'll work on that.

Re: Pluggable protocol handlers... (Michael...)

I've written one from scratch to allow web sites to live in offline Exchange public folders and there is was a fairly sophisticated example in the MS KB (but I just looked and it's not there anymore).

If someone has a lot of money (seriously), I can write another one.

Michael.

http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/pluggable/overview/appendix_a.asp

- to handle grooveDatabase://, grooveTelespace://, etc... and have that sort of link (Groove canonical URLs) work from a browser.

Chat Archives

Re: Chat Archives

Jeroen Bekkers/Suite75: 6/6/02 4:55 PM

yep tool installs

Tim Knip/Suite75: 6/6/02 4:55 PM

but doesn't post...

Tim Knip/Suite75: 6/6/02 4:56 PM

hmmm, blogger.com is probably too busy again...

Tim Knip/Suite75: 6/6/02 4:58 PM

will finish the Radio-version tomorrow guys..

Jon Udell: 6/6/02 7:21 PM

The XML-RPC version should work for Radio as well. But I forget how the config goes. Radio ignores BlogID, uses Name/Pwd, but what about homepage?

Tim Knip/Suite75: 6/6/02 9:38 PM

Jon:

Tim Knip/Suite75: 6/6/02 9:38 PM

I have all bits and pieces working, just have to wrap it up in one tool

Tim Knip/Suite75: 6/6/02 9:39 PM

this one: blogger only

Jon Udell: 6/6/02 10:00 PM

Not that it matters much but, since Radio does support the Blogger API (and I've used it successfully) how could your Blogger API tool *not* support Radio too?

Tim Knip/Suite75: 6/6/02 10:05 PM

uh: some link is hard-coded...

Jon Udell: 6/6/02 10:06 PM

Oh :-)

Tim Knip/Suite75: 6/6/02 10:06 PM

ehe

Jon Udell: 6/6/02 10:14 PM

Jeroen, I wonder if you could add the Cabezal News Tool to this space? I've downloaded, but I guess owner privilege needed to install.

Jeroen Bekkers/Suite75: 6/6/02 10:17 PM

yep i can add it , but i was wondering if i should because it forces the extra installation of a tool

Jeroen Bekkers/Suite75: 6/6/02 10:18 PM

but i guess it would be not a big problem

Jon Udell: 6/6/02 10:16 PM

Which extra one? What would the consequences be?

Jeroen Bekkers/Suite75: 6/6/02 10:19 PM

The newsclinet tool is not a standard tool so it has to be installed, just like the blogger tool but we allready added that one so why not the newstool

TimA: 6/6/02 10:18 PM

Exactly Jeroen, and then I don't have to go and find it myself and try it out myself in another space!!

Jeroen Bekkers/Suite75: 6/6/02 10:20 PM

hehe

Jon Udell: 6/6/02 10:19 PM

Is adding channels only for the space owner?

Jeroen Bekkers/Suite75: 6/6/02 10:24 PM

not anymore

Jeroen Bekkers/Suite75: 6/6/02 10:25 PM

everybody can add feeds now

Jon Udell: 6/6/02 10:26 PM

This is excellent, thanks! A question for Hugh (when he shows up): what level of development efffort would be required for NewsClient to support the Navigate Together feature?

Jeroen Bekkers/Suite75: 6/6/02 10:30 PM

must not be that difficult, serch would be nice too :-)

Jon Udell: 6/6/02 10:29 PM

Search would be nice everywhere, of course. Nobody should have to work to make that happen, it should simply exist.

Jon Udell: 6/6/02 10:30 PM

This is just verifying that item-level linking is present and working: Tim Knip: Check out my first file...

TimA: 6/6/02 10:30 PM

I'm still running a Preview edition of Groove here. You telling me that SEARCH is not part of the regular version????

TimA: 6/6/02 10:31 PM

BTW Jon, that link doesn't seem to work.

Jon Udell: 6/6/02 10:31 PM

Hmm. What *should* that link do? Take you to the item in NewsClient and highlight it, correct?

Jon Udell: 6/6/02 10:35 PM

TimA: Yes, sigh, it is not. And no, the link seems not to work. But I'm sure it can be made to do so. The general behavior in this situation is that you do a Copy Link -- in this case of an RSS item -- and then paste a Groove-style link into any document, including chat. I'm seeing this a really useful tool for a group of reporters (which is my day job now :-) ) who are collectively watching some set of feeds, and isolating particular items for further discussion/analysis.

Jeroen Bekkers/Suite75: 6/6/02 10:37 PM

agree on search, it's not in any Groove version but it should be ASAP and print too ;-)

Jon Udell: 6/6/02 10:40 PM

Really intersting, Jeroen: Andy Swarbs has been setting up and maintaining interesting public Groovespaces for some time now... . It's cool that I found this in Radio's aggregator, then flipped screens and it was here too -- persistently.

Jeroen Bekkers/Suite75: 6/6/02 10:42 PM

:-)

Matt Pope/Groove: 6/6/02 10:44 PM

Search & Print... sigh sigh sigh. We're aware, we here you (& everyone) and, as users, we agree. They're coming.. just a matter of resources, time and a bit of code:-)

Hugh Pyle/Groove: 6/6/02 10:45 PM

NB: the newsclient isn't particularly robust... if it flakes out, caveat lector :-)

Jon Udell: 6/6/02 10:41 PM

I know. It's a Simple Matter of Programming :-)

Jeroen Bekkers/Suite75: 6/6/02 10:43 PM

yep i know you're very aware of it , i have some patience :-)

Jon Udell: 6/6/02 10:43 PM

Hugh: Even so, it's immediately useful. 1) So a group can collaborate around a shared set of feeds. 2) So that such collaboration can refer to persistent instances of items in the feeds.

TimA: 6/6/02 10:43 PM

Sorry to bring that up but someone told me it already existed. Obviously they were wrong!!

Hugh Pyle/Groove: 6/6/02 10:48 PM

Re: navigate together in newsclient: NewsClient and NavigateTogether (Hugh Pyle)

TimA: 6/6/02 10:46 PM

Jon, did you notice the comments button. You can enter comments per feed item. Doesn't show up anywhere that I can see unless you press the button however.

Hugh Pyle/Groove: 6/6/02 10:51 PM

Exactly: the comments don't even show in the main view (which is kinda dumb).

TimA: 6/6/02 10:47 PM

This is a work in progress though isn't it?

Hugh Pyle/Groove: 6/6/02 10:52 PM

It's more like "work in the freezer". The code is owned by agora.co.uk but they don't have a lot of (financial) motivation to do more with it at the moment.

Hugh Pyle/Groove: 6/6/02 10:54 PM

In terms of "neato tools", though, NewsClient is almost as good as PinBoard. (heh)

Hugh Pyle/Groove: 6/6/02 10:54 PM

Whoo! Blogger tool!

Jeroen Bekkers/Suite75: 6/6/02 10:53 PM

does it post now?

TimA: 6/6/02 10:51 PM

Understood Hugh!! Too bad it isn't open source then someone can just pick it up where it left off.

Jeroen Bekkers/Suite75: 6/6/02 10:53 PM

aha, i see it does now

Hugh Pyle/Groove: 6/7/02 9:51 PM

Goodness, this space is getting busy now.

Sean Heffernan: 6/7/02 9:48 PM

guess that happens when so many folks publish/link to the invitation

Hugh Pyle/Groove: 6/7/02 9:52 PM

Indeed....

Hugh Pyle/Groove: 6/7/02 9:54 PM

So have you been using groove much at sysinct?

Sean Heffernan: 6/7/02 9:50 PM

used in on some development projects with mixed success

Sean Heffernan: 6/7/02 9:51 PM

would have had better success if there was a more robust requirements / issues tracking tool available.

Hugh Pyle/Groove: 6/7/02 9:56 PM

Right - have you looked at the forms tool? That's just about the most flexible way (unless you want to build your own)

Sean Heffernan: 6/7/02 9:52 PM

not that we're adverse to building such a thing but its tough to justify non-billable work of that nature

Hugh Pyle/Groove: 6/7/02 9:56 PM

I know, exactly.

Sean Heffernan: 6/7/02 9:52 PM

i have not looked at the forms tool .... most of use fell away prior to 2.0

Hugh Pyle/Groove: 6/7/02 9:57 PM

It's pretty simple - just forms, fields, views - but flexible enough.

Hugh Pyle/Groove: 6/7/02 9:59 PM

So where do you see Radio and Groove? I want to hook them together, but I can't tell how geeky that makes me :-)

Hugh Pyle/Groove: 6/7/02 10:02 PM

I just wish I could blog effectively without switching context. That doesn't just mean "from inside Groove", but of course I spend a lot of time in Groove spaces. So like now, I want to put this URL: http://hyperorg.com/blogger/archive/2002_06_01_archive.html#85147241 and say stuff about smarttags... I want to do that right here, but also onto my weblog...

Hugh Pyle/Groove: 6/7/02 10:04 PM

Tim's blogger tool is a good step towards doing that. But the blogger tool right now is about "collaborative blogging to a single blog". Maybe something like "collaborative context, but everyone blogging to their own blogs, and their posts-from-the-space also being immediately visible-in-the-space. That could be really useful.

Hugh Pyle/Groove: 6/7/02 10:07 PM

I think the "post invitation files" piece is quite peripheral to what's really interesting about the things we're discussing here, though. Breaking the boundary of the space is more about the content (and context) than about the participation. Every time a stranger appears in a group, the dynamics change.

Jeroen Bekkers/Suite75: 6/7/02 10:06 PM

agree, this is probably a scenario most interesting for us at this moment, Tim's bloggertool is for the people who normally won't setup a weblog to make it more accessible to psot at all

Hugh Pyle/Groove: 6/7/02 10:08 PM

Hi Jeroen

Jeroen Bekkers/Suite75: 6/7/02 10:06 PM

Hi :-)

Jeroen Bekkers/Suite75: 6/7/02 10:06 PM

i stopped greeting so many people and changes ;-)

Hugh Pyle/Groove: 6/7/02 10:09 PM

Tim's tool is really great... as with all these things, it's only by using them in a real scenario that yu get to explore how the tools actually "feel".

Sean Heffernan: 6/7/02 10:06 PM

coincidental thinking here Hugh ... I just posted something to the discussion forum that make reference to similar concepts

Jon Udell: 6/7/02 10:06 PM

Hugh: "Breaking the boundary of the space is more about the content (and context) than about the participation. Every time a stranger appears in a group, the dynamics change." Can you elaborate, Hugh?

Hugh Pyle/Groove: 6/7/02 10:11 PM

Hi sean - yes, good post

Hugh Pyle/Groove: 6/7/02 10:13 PM

Jon: well, you go from feeling like a small binch of people sitting around a table over coffee, to "who's that Sean guy", to "He's OK, writing some useful things here". But that process takes a while, and affect also my feelings about past writings. Am I writing this stuff with a Groove Networks Inc. hat on? No, of course not; it's more informal than that. Could a stranger quote out of context, and make me hold to my words? Of course; I like the rheingold-type "you own your words"; but the public-private boundary shouldn't be too fluid...!

Jon Udell: 6/7/02 10:12 PM

Hugh: Understood. I asked my self today, what is different here from a TakeItOffline (QuickTopic) discussion? Somebody dropping in from the outside with no Groove experience might think, "Not much." Or, they might look at the shared RSS feeds and think, "OK, that's novel, I couldn't do that group-feed construct anywhere else." From a Groove perspective, though, I see your point. People drop in and out of web discussions and newsgroups with no effect on the group. Here, it's more unsettling because of the greater awareness of the composition and presence of the group.

Hugh Pyle/Groove: 6/7/02 10:17 PM

Then there's also a mix of people who have met F2F and not. For me, I've met: Jeroen, Tim, Michael, Sanjay, Clive, Mark... and I've read your writings often, so I know a little of who you are. But I don't know sydbarrett74 (say). Everyone is "present" in a concrete way, unlike a newsgroup or many other discussions.

Jeroen Bekkers/Suite75: 6/7/02 10:18 PM

yes, i'm becoming more and more curious how this affects the way people take part in the discussion is it catalyzing or do people feel more reservations on speaking their thoughts the crowdier it gets.

Sean Heffernan: 6/7/02 10:17 PM

i for one, while lurking for a while yesterday, felt somewhat intimidates by Jon, having been reading his stuff since way back in the his early Byte days.

Sean Heffernan: 6/7/02 10:18 PM

thusly, not feel comfortable posting

Hugh Pyle/Groove: 6/7/02 10:22 PM

heh. "Do Not Intimidate Thyself" being a good motto

Jon Udell: 6/7/02 10:19 PM

Hugh: I see your point. I agree this fully public mode is a little odd from a Groove perspective. What might be more natural is the moderated mode that Jeroen considered but did not implement, which would require him to confirm all invitations. Then two things could happen. One, participants could individually blog items. This is already happening, of course, and doesn't at all require (though would benefit from) direct tool support. Two, the space itself could simply echo out to the web, thus effectively becoming like a moderated newsgroup that is world-readable but only invited-group-writable. Problem there: the full context is spread across chat, discussion tool, news client, potentially other tools. How to faithfully export the whole thing is not clear.

Jon Udell: 6/7/02 10:19 PM

Sean: I'm only making it up as I go along, just like you :-)

Sean Heffernan: 6/7/02 10:19 PM

true enough

Hugh Pyle/Groove: 6/7/02 10:24 PM

It's possible to export *some* faithfully (easyweb did quite a good job of discussion, outliner, pinboard, files). But there are more dynamic things which don't translate so well.

Jon Udell: 6/7/02 10:21 PM

This is a little like parties at my house. We always try to get people to move into the living room (aka, the Discussion tool). But they keep on congregating in the kitchen (Chat tool). When we moved to a new house that is bigger, but with a smaller kitchen, I thought it would solve the problem. But nope. Everybody still piles into the kitchen :-)

Jeroen Bekkers/Suite75: 6/7/02 10:23 PM

lolo

Hugh Pyle/Groove: 6/7/02 10:25 PM

I gotta go - late here... (I should be celebrating our win down the pub, anyway!)

Sean Heffernan: 6/7/02 10:22 PM

closer to the beer

Jeroen Bekkers/Suite75: 6/7/02 10:24 PM

congrats btw , nice match

Sean Heffernan: 6/7/02 10:24 PM

"But there are more dynamic things which don't translate so well." ... I would imagine in that context then it would be up to the tool design to provide the necessary output translation that would allow blog posting ... or not at all, it the just does not translate at all.

Jeroen Bekkers/Suite75: 6/7/02 10:26 PM

agree btw that a more controlled space seems more logical using Groove but i was kind of curious how this experiment would turn out, and didn't want to bother to discuss who should join and who not, just wanted to have a discussion :-)

Jon Udell: 6/7/02 10:32 PM

Jeroen: " i was kind of curious how this experiment would turn out, and didn't want to bother to discuss who should join and who not," - and that was exactly the right thing for this purpose. Too many people have simple not been exposed to Groove at all. There need to be low-activation-threshold ways to experience it, and this is one.

Jon Udell: 6/7/02 10:37 PM

Sean: " it would be up to the tool design to provide the necessary output translation" - OK, but the more burden you lay on the tool builder, the fewer tools we get and the slower they are to develop. I should think the tool framework would provide some reasonable default behavior for: wholesale exportation to the web, item linking, item summarization, and other things that have come up in this discussion. I ought to be able to build a useful tool, in script, in 2 hours, that adds value for my group. I can do that in Radio, and in lots of scripting environments (e.g. Zope) because of the combination of high-level scripting and a framework that supplies adequate defaults for those things I don't explicitly handle. Groove seems still much more attuned to the professional GDK-level developer, like a lot of you guys are, but almost nobody else is.

Jeroen Bekkers/Suite75: 6/7/02 10:41 PM

That's true, i hope the next version of the forms tool combined with edge services can provide this

Sean Heffernan: 6/7/02 10:41 PM

fair enough, but as part of their edge services development, Groove could build in the necessary architectural components to handle this translation as well as corresponding links to associated blog urls (etc.) (i.e. allowing me to set what my blog url for posting is at the account level) and then providing tool designers easy to use UI widget that all them to "place post to blog ui widget here", then we would lower this theshold.

Sean Heffernan: 6/7/02 10:45 PM

being able to publish select discussion posting to a personal blog / group blog, as you manually did Jon in replicating your posting in your radio, almost in a sense broadcasting what is taking place "in the kitchen to those still hanging in the living room", you are in essence attempting to lower the activation threshold ... or at least making other curious as to what's up in the kitchen, perhaps even enough to make them wander in.

Hugh Pyle/Groove: 6/7/02 11:19 PM

Jon "I ought to be able to build a useful tool, in script, in 2 hours, that adds value for my group" - yes, agree. With the model of "build a new tool", our target environment to make that happen is VS.Net (and we're a long way down the line of having that happen already). With the model of "build a little database-like app with some logic", the forms tool supports user/developer scripting for that logic. Then edge svcs should be accessible from (eg). SOAP::Lite.

Space defintions

Having read here some threads herein around what can/should be made public from Groove in terms of blogging. Part of the debate discusses the public/private space boundary. To help this along I offer some defintions to help focus when a public boundary may or may not be appropriate.

Private Space

A space that only "I" belong to. "I" may include several accounts. Content may include passwords and other personal information. These spaces will NEVER be shared with others.

Personal Space

is one that holds personal information. perhaps it may be master copies of my CV. It may be family pictures or family accounts. These spaces would be shared with my family.

...also just personal research (like info about my Massey-Ferguson tractor) that I haven't found anyone to share with.

Public Spaces

Are ones where membership is OPEN to a wider audience. Perhas a .GRV invitation file is registered on a website.

These spaces are potential for blogging

Foriegn spaces

are spaces that you belong to where your role is participant or guest as a result of you joining someone-else's space.

Shared space

A space which is shared amongst co-workers. This space is a good example.

My own conclusion is - JUST DO IT - but let members know that it is happening.

Space Policies

Whether space content is or is not made public should not be a matter of debate. The space owner (a non-existent entity in Groove) should set out clear terms and conditions of membership. If one of those is stated clearly that one or more tabs is to be blogged onto a website etc - then who can complain!

Suggestion: "Publish as..." menu item on each tool tab's pop-up menu

Andy's comments triggered some more thoughts around the "unfettered" integration topic I mentioned in the problem definition discussion (What is the definition of the problem we're trying to solve? (Michael Herman (Parallelspace V2#3))).

The "new" thought is the you should be able to right click on any tool's tab and select the menu item

Publish as ...

(or something equivalent) and up would pop a dialog box (or wizard) that allows you to select any of the two-way collaboration and one-way publishing destinations you'd like the content of the specific tool to synchronized with or published too.

Once a tool had been Published, some distinguishing mark (e.g. icon) would appear next to the tool's name in the tool tab.

Cheers,

Michael.

I would be far more worried about issues such as being invited to a space called "coffee machines" whose content was all about terrorist activitities. Currently there is no way of knowing BEFORE you join a space what you are letting yourself in for. There could be size problems (imagine being invited to a space of size 100gigs!), political problems (aka terrorist), illegal problems (porno, drugs). The list is endless.

This is where the debate around public/private issues should exist, that is what public information there exists about a space before one joins the space. Groove 2.x began to think about the isse with the Welcome tool. But unfortunatety it missed the boat. It misunderstood the question, imo and went for an easy but useless answer. I mean, in a busy space WHO will actually use a Welcome tool! It is just a waste of space!

The only current value-added of the Welcome tool is the description. But does Groove push the boat out and ask the question should / can the welcome information be made available to non-members? No it does not. It ducks out of the question, possibly afraid of the answer.

This is a VERY important question. For example suppose I was George W Bush and someone I trusted invited me to a complex space. A few weeks later in a press meeting some journalist posed the question. "Mr Bush is it true that you are a member of a Groove space shared with the Al-Queda". Now remember that Groove keeps no logs of membership changes (though this has been requested). So an Al-Queda person could be an ex-member! Thus it may be difficult for GWB to know in the first instance about the problem. But the trap is sprung! And I bet you this will happen one day!

An additional axis: Shared Knowledge Spaces and traditional Shared Collaboration Spaces

When I look at the 175+ shared spaces I've either created or otherwise joined over the last 14 months, I see at least two distinct categories:

1. Traditional Groove Shared Collaboration Spaces that primarily have a collaboration focus. This Radio space is an excellent example.

2. Personal or Public Shared Knowledge Spaces where I've used Groove as an excellent organizating structure for a rich collection of information and knowledge about a personal or business topic. For example, my Massey-Ferguson MF-165 Tractor space which holds everything know and have learned about this particular make and model of tractor.

Michael.

Can the NewsClient be moved to a shared space of it's own?

It causes this space to have a perpetual Unread mark associated with it.

Re: Can the NewsClient be moved to a shared space of it's own?

yep, noticed it too, tried to put in a toolset but even then you can't control marks like in other native 2.0 tools. Don't know how other people think about it, having it placed in another space reduces it usefulness a lot in this context i think.

I'd be tempted to delete it from here

Y'all can inject your own copy if you want, from

recommend we delete

constantly updates the unread flag and we have no way in this version (of the tool) of setting that off from the Tab - it's a 1.3 tool

ok done

http://www.cabezal.com/Products/NewsClient/

Please move the NewsClient to a shared space of it's own.

Thanks,

Michael.