I have been against the use of PUT and DELETE in the Atom API.  My reasoning is that PUT and DELETE support is spotty and use is rare which means they are not as proven as GET and POST.  Another concern I had was that those who were pushing for PUT and DELETE weren't looking at all sides of the problem.  For example, Atom wiki's CarrotVsOrange page which enumerates the issues listed only server-side platform support information.

Early this morning, I prepended "Server-Side" to that section's title and added another section for client-side.  By 4:30PM, the section has filled up and, although still incomplete, clearly shows some spotty support of PUT and DELETE on the client side.  It's a wonderful display of Wiki power.

There also also the proxy and firewall to consider.  I may create a separate section for that as well if others don't.

Please take a look and help out to complete the section (1.6).

Thinking about Virtual Memorials touched off another idea: using walls of virtual world as wiki pages.  Flipped it around and you have a wiki organized like a real world building along with some visual hints to enforce the building metaphor.  Such a wiki could be useful for conferences.

My previous post on Virtual Protest and today being 9/11 made me think of Virtual Memorials.

A Virtual Memorial can be as rich as Star Wars Galaxy or EverQuest in full 3D or as simple as text-only MUD or MOO.  As long as it is immersive enough to captures the event in both space and time and let visitors interact with each other, technology doesn't matter.  Go there and maybe one can see the people who there and are no more.  Sit there along aside and experience the event unfold.

Inside the Virtual 9/11 Memorial, everyday is September 11th, 2001.  Inside Virtual Pearl Harbor Memorial, everyday is December 7th, 1941.  A place to go and remember the day.  Maybe share a line or two of thoughts with others.

Ease of Use is a major factor in Micropayment, but no one knows for sure how much of a factor it is.

My guess is that if all that stands between the user and paid-content was a hyperlink titled "Read for 25¢ IOU", most people will click through.  Actually billing takes place when the amount owed to a particular site goes over certain amount ($10 sounds reasonable).  At 25 cents, that's 40 articles you can read before you are asked to pay.  I would guess further that most people who like to read will opt to pay the bill even if they decided to stop reading content at the site.  If they refuse to pay, then service is degraded in some way for the user.

The scheme outlined above will exhibit different results depending on the type of content and target audience.

In response to my RFID in Efficient Government post, Shawn of TextAmerica (no last name, probably Shawn Honnick) mentioned Stop RFID Moblog, a site for organizing a "virtual protest" around an actual protest taking place on 9/16 in Chicago.

Nice thought except the planned "virtual protest" seems rather wimpy.  Stop RFID Moblog suggests this:

Those of you who who cannot be there due to time and travel constraints can participate by protesting locally and sharing your protest sentiments virtually, right here.

Please email your anti-RFID protest photos and comments to this site via stoprfid.1@tamw.com. Please also send a copy to us at the following email address: protest@stoprfid.org.

Like I said, well intended but whimpy as a protest nor an attention getter.  I guess all those Think Different billboards Steve Jobs put up were wasted.

If I was organizing it, I would create a Virtual Protest Ring Tone, something that say something about the protest, a jingle or a chant, whatever.  Let people show their support by downloading it and installing it on their cellphones so people around the supporters will notice and ask

Why does your phone say STOP RFID instead of ringing?

Then every phonecall received turns into an opportunity to further the cause.  Charge for the ring tone if the cause is worthy and in need of money.  For TextAmerica, it would generate publicity and encourage meaningful use of ring tones.

<

p class=”textarea” dir=”ltr”>An obvious variation is "Howard Dean for President" ring tone.  Oh, well.  I am sure Howard has plenty of helpers to tell him about it.

More I think about RFID, more doors open up.  While thinking about the privacy issues rising from associating RFID with a person via purchase records, I thought of a couple of unique ways RFID might be used.

One idea is to record RFID tags on people and things moving in and out of an area through gates.  An alarm is raised when an unknown RFID is detected within the area.  Software is simple, just a database of RFID tags with optional good-til timestamp so Pizza can be delivered within the area.

Another idea is to use a set of RFID for authentication like "Please Wear Yesterday's Underwear to Authenticate".  Seems silly at first, but requiring a minimum number of RFID known to be owned by a person or asking for a specific RFID to authenticate is not entirely useless.

Update #1:

Alient Technology RFID tags can be read 15 feet away.  That's enough to cause concerns.  In fact, I think RFID tags with wider range than average 'personal space' is of concern.  RFID tags with smaller range usually requires violation of personal space like waving a hand-held metal detector around your person.  Of course, hidden readers like 'shoe-readers' embedded in a line of bricks along a walking path is a problem.

Perhaps some legislation is necessary to require readers to be clearly marked and readers for RFID tags with wide range be licensed to be usable within specific areas.   Requiring RFID readers to have embedded long range RFID tags is can help so one can walk with a RFID detector and not worry about RFID readers.  Same can be used to make sure long range RFID readers stay where they are licensed to operate.

Another thought is that 'Opt-Out' RFID tags might be a good compromise.  I could wear one as a necklace and it could tell RFID readers to ignore any RFID tags I might have on.  Again legislation is necessary so this behavior can be built-into RFID readers.

Mark Roseman of CourseForum Technologies, a commercial Wiki vendor, contributed via e-mail, his perspectives on the ongoing discussion over commercial vs. open source Wiki products and comments on using Wiki for blog comments.

The response from Ross about Socialtext touched on what a commercial system (like theirs or ours) can offer. As you say, issues surrounding support, hosting, integration, documentation etc. are fairly obvious. Let me elaborate a bit more about a few things.
Ease of use
Tools like TWiki do a reasonable job of covering the 'geek' market, but when it comes to making tradeoffs about adding more power features vs. keeping things simpler and more accessible, tend to lean towards the former. Our system tends to keep the markup simple, add features designed to help new users such as preloading forums with some default content, page templates, allowing people to post comments without going through the full edit interface, etc.
At the same time, the system is fully featured to suit what people need to do, has things like user tracking, decent security models, versioning, archiving etc. that aren't necessarily fun to code but are needed when Wiki's are used in "real" environments. But the application as a whole is designed in a way that features are presented in an accessible but not obtrusive way. You don't always get that mindset from developers who haven't done a lot of commercial systems before (ok, or some that have!).
Ease of install/setup/admin
This is one area where the open source packages usually fall down, because they rely on many other packages which must be installed and configured.  Something like Twiki usually needs setup of Apache, configuring MySQL databases, various other modules, setup CVS to do version control, etc. Further, most of the configuration is done through manually editing configuration files or variables at the top of code files.
We like to point out this article about what is usually involved as compared with ours (just double click a single executable, no configuration needed, and later administration done via a web-based interface).
On top of the configuration hassles and software dependencies, most of  the open source systems are fairly platform-specific; one differentiator for ours is that it runs well on not only Unix, but also Mac and Windows.
This (and the previous point) really help bring the whole Wiki concept to a much wider audience; going in to configure software and then making it hard to initially figure out really restricts who can take advantage of the software (and we've had more than a few hard-core geeks buy our stuff after getting frustrated trying to get Twiki or similar systems installed!)
Multiple workgroups
Most Wiki's grew out of personal use projects hacked together (your comments are astute; rip everything away and there isn't necessarily much there).
As such, they tend to hardcode a lot of assumptions. Many of these mean that its very difficult to setup multiple separate workgroups/wikis on a single server, or that you need to install multiple copies of the software to do so. Changing that would be a major redesign (and its not an issue for most of the open source developers working on those systems).
In ours, multiple distinct workgroups can seamlessly exist on the same server; this was designed in from the start and is important for our target audiences (in most places you'd have one person maintaining a server for a lot of other people, rather than everyone running their own copy of the software).
Wiki's replacing blog comments
I think this is on the right track. We've seen a comparable thing in our educational product, where instructors would post slides from a lecture on a Wiki page, and then students would post their comments and questions on the same page. The parallel with blog posts and followups is fairly natural.
The sticking point with doing this for a lot of Wiki's is that you don't necessarily want people deleting or changing each other's comments. Some of the more advanced Wiki's would help with this. In ours for example, you can:

• make it so that people can post to the end of the page but not edit existing contents
• have a more closed forum where users are authenticated
• track a history of changes to the page, so if something was deleted or changed, you can find out what, when and who did it

Bottom line
Ok, I think I'd better stop before I overwhelm you. 🙂
But I really do want to second Ross' comments about commercial Wiki's complimenting rather than competing with open source alternatives.  I've been working on collaborative systems for a long time, and was really impressed with the potential inherent in the core Wiki idea (no matter, or perhaps because of, how simple that idea is).
What we're trying to do is take that core idea and make it a lot more accessible, bringing it to a wider audience, people who would never really be able to benefit from it with existing tools.

FYI, CourseForum Technologies has two products: ProjectForum for business (demo) and CourseForum for education (demo).  There is also a large public project based on their software.