| |
 |
Monday, June 10, 2002 |
|
Radio supports XCOPY deployment
Kevin Altis ran into some admin trouble with Radio:
Since Radio doesn't have a sync feature, so that two machines can run Radio, but keep their data up-to-date on both boxes which seems like a pretty basic feature to me, I'm going to install Radio on my notebook this time, so I can blog while travelling. I was tempted to simply use file synchronization between my desktop and notebook, but given the number of files and object databases Radio uses that sounds like a recipe for disaster. [Kevin Altis' Radio Weblog]
FWIW, my recipe for backing up Radio, and also transplanting it to/from my notebook PC for travel, is simply:
xcopy /s /d C:\radio\. T:\radio\.
In this era of fast networks and capacious hard drives, it's really no problem.
BTW this feature, long missing from Windows due to registry entanglements, is touted as a new thing -- "xcopy deployment" -- in the .NET marketing literature. Works in Radio too :-)
5:33:04 PM 
|
|
|
Ruby (the language), TupleSpaces, REST, and Ruby (Sam)
I wish I could point to an article by Dave Thomas and Andy Hunt in the April issue of Linux Magazine, because it has a beautiful example of a chat system done using Ruby's tuplespace and drb (distributed Ruby). I'll link to it when it posts. Here's what reminded me of it:
Patrick Logan: This is a pretty good analogy because SQL is an unbelievably limited query language just as REST is an unbelievably limited, er, whatever it is supposed to be.
Patrick also has other good recent blog entries on REST and TupleSpaces. [Sam Ruby]
A while back, I echoed similar themes in a BYTE.com column
The authors of Programming Ruby, Dave Thomas and Andy Hunt, authors characterize the language as "the Perl and Python of the new millennium." Rich Kilmer, who is contributing to an IDE for Ruby, enthusiastically concurs. To my eyes, as an observer but not yet a user of Ruby, it offers some nifty features both as a language and as an environment. On the language front, it puts blocks, closures, and iterators to powerful use, as Thomas and Hunt show in their book and also in a recent DDJ article. As an environment, it augments the usual stuff with some really interesting modules. Rich Kilmer raves most often about Ruby's tuplespace module, which implements a shared bulletin board (à la Linda or JavaSpaces) that can be accessed using complex patterns, and also about Ruby's RMI-like feature, drb (distributed Ruby), which makes it trivial to wire up networks of these tuplespaces.
To close the loop, Sam Ruby's O'Reilly Network blog asks:
The REST wiki suggests that the REST architectural style is most closely related to that of TupleSpaces. One important difference is that in TupleSpaces the sender does not identify the recipient. Data is addressed and routed based on content. Is there a place for such a model in "Alternative Web Services Architectures"?
Is it my imagination, or is everyone and everything now connected to every other one and every other thing? Well, at least Sam isn't programming in Ruby...yet :-)
5:08:09 PM
|
|
|
This phase of the Groove/weblog experiment is concluding
The Groove/weblog experiment has run its natural course. Jeroen plans to shut down the space. He writes:
-The space is becoming quite heavy the more people join and probably we'll start having sync alerts very soon, cause some people won't check the space regularly
-The number of posted items seems to have an inverse relatioship with the number of peope in it, more people, less posts
-The discussion has been published to the web for future reference, content only no names check: http://radio.weblogs.com/0107414/opml/radiointegration.html
-The more public the data gets the more people are feeling uncomfortable with it being public.
-Let's continue the discussion on our weblogs and smaller private spaces.
Agreed. It has served its purpose. At the moment, I count 36 members in the space. It's nice to know that's possible, but Jeroen's right, it has passed the point of diminishing returns.
I look forward to continuing the dialog in other venues, both inside and outside Groove.
11:09:52 AM
|
|
|
Matt Mower on community formation in blogspace
Matt Mower has posted some interesting thoughts on community formation in blogspace:
The analysis of common links whilst interesting unfortunately does not address the central problem of finding your community since, if you are already linking to the same sites, it is quite likely that you are already homing in on the community. This may be just telling you what you already know!
Your membership of a BlogPlex should be implied by posting something, anything. The semantic content of your posting defines the BlogPlex that you create (or joins it if it already exists) and new members of a BlogPlex can be automagically hooked up. [Curiouser and curiouser!]
I think he's right to suggest that group membership is becoming a more fluid concept than it traditionally has been. Or perhaps that's the wrong way to put it. In ordinary social life, groups can be transient and implicit as well as long-lived and explicit. The only tool we've had for ephemeral and spontaneous group formation is email. That will surely change, and the flurry of social networking experimentation we see all around us suggests that the evolution is now underway.
10:45:17 AM
|
|
|
Managing identity in Groove public spaces
More notes from the Groove/weblog frontier. John Burkhardt:
The space started out with 4 or 5 of us, and in my mind a Groove shared space is private. Then the link got posted to the web, then the entire contents of the discussion got posted to the web. [John Burkhardt, via Scripting News]
Dave Winer:
By design, Radio makes it easy to make things public. On the other hand, Groove wants to keep everything private. The connection between the two products should reflect their nature. Publishing should be an overt act in Groove, something you do deliberately. [Scripting News]
I hope nobody felt "outed" by Jeroen's posting of the .GRV link (that is, an open shared-space invitation). It's not normal protocol, but in this special case I think it was exactly the right way to put some crucial issues under the microscope.
One of them, which I didn't mention yesterday, is the way in which an open-invitation shared space, if not configured to require confirmation of acceptance (as Jeroen's wasn't), exposes Groove vCards to public view.
John Burkhardt:
I might not want anyone in the world to get my vcard - but now they can! ... 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.
One solution to this dilemma is to project a secondary identity into such a shared space. In Groove, the notion that you can maintain multiple identities and selectively project them into spaces is a basic principle. Because we lack cultural traditions for doing this kind of thing, it's probably not much utilized.
So, to sum up some lessons learned over the past few days:
- A Groove shared space, in toto, is not usually the best place to have a public-discussion that's open-ended in terms of the number of people who can join. Why not? Relatively heavyweight, more intimate than necessary for the purpose, not really compatible with Groove's trust model.
- But in special circumstances, it can be configured this way. Why? To maximize the "horizon of observability," demonstrate Groove capabilities to non-Groove users, or leverage Groovey capabilities not otherwise available in ordinary public web spaces.
- In such cases, the space is implicitly available for blogging and other exportation of content.
- However, the policy should be stated clearly up front.
- Groove's Welcome page is not yet a well-established way to advertise such policy.
- Identities should be projected into such public spaces with care, as they are exposed in ways not really compatible with Groove's trust model.
9:40:06 AM
|
|
© Copyright 2002 Jon Udell.
|
|
