Title

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 . 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.

Re: Public Groovespaces

> Not all groovespaces will have the need to be private and secure but do have the need for > 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

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. 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

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?

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.

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. ...sounds like EasyWeb?

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 :-)

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) - 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.

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 tool.url Functionality: everything you would expect from a simple aggregator. No more.

NewsClient and NavigateTogether

Should be reasonably straightforward. The bigger question is: who has the time/motivation to do it :-0) 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 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.

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.

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, > 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.

"Activation threshold"

Good term. 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?

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

Re: there's a social threshold to cross before you press it. 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.

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. 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

Re: MSN messinger is more instantaneous but less secure.

I would like to understand how Messenger is "less secure"? 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.

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

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..." - 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

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.

Re: General question for Jon

Jon may appreciate this thought most. 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

mind of Dave / mind of Ray

You may well be right. Where that leads us, I am not sure :-)

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. :-) ...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.

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

I was just thinking about this too I think... 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.

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?

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

Tim Knip/Suite75: 6/5/02 10:48 AM 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/

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)

"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. 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.

Radio integration suggestion

How about: publish the contents of all your Groove spaces as RSS feeds? - 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)

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? 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: 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).

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. 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)

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? 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.

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

records... got details from the discussion TPL

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).

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. 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

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. 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.

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 > 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 :-)

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? Don't limit me, as a developer, to subset A or subset B. Michael.

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. 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.

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.

"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. 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).

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? I'm just trying to be pragmatic here as far as the real world of enterprise customers is concerned. Michael.

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...

HTTP and local webservers

Is this a viable infrastructure? (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)

Re: HTTP and local webservers

Re: [Are HTTP and local web servers] a viable infrastructure? These are the very next levels in the communication stack above TCP/IP and DNS, n'est pas? Michael.

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.

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? 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.

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. 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.

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.

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: 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.

Re: Activation threshold & the experience

Neat idea. (Are you sure we don't want to drag people into the Groove UI, Matt?!) 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

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.

Re: Activation threshold & the experience

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

Basic onramp to this space from my weblog

I posted the link to this invitation file on my weblog: http://radio.weblogs.com/0104207/ 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. ;-)

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! 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

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

Re: Basic onramp to this space from m