#!/usr/bin/perl use CGI qw/:standard :netscape/; use POSIX qw/strftime/; print "Content-type: text/html\n\n"; $page = param(page) || substr(path_info(),1) || 1; ($q,$ext) = $ENV{SCRIPT_NAME} eq $ENV{PATH_INFO} ? ('?page=','') : ('','.html'); $data = join("",); $data = "$1$2$2$3" while ($data =~ /(.*\n)(===.*?\n)\.\.\.\n(.*)/s); @data = split(/\n===\s*/s, join("",$data)); ($title, $body) = ($data[$page] =~ /(.*?) ===\s(.*)/s); for ($i=0; $i<=$#data; $i++) { $title[$i] = $data[$i]; $title[$i] =~ s/ ==.*//s; }; print < XMLConf: $title EOH if ($page =~ /contents-?(\d*)/) { $page = $1 || 1; shift @data; $prev=''; foreach $page (@data) { ($title, $body) = ($page =~ /(.*?) ===\s(.*)/s); $i++; next if $prev eq $title; $prev=$title; push @contents,"* <% $title %>\n"; } undef @data; for ($i=0; $i<=$#contents; $i++) { $data[int($i/12)+1] .= $contents[$i]; } $title="Contents"; $q .= "contents-"; } print "\n"; print "\n"; print "\n" unless ($prev=$page-1)<1; print "\n" unless ($next=$page+1)>$#data; print "\n\n\n\n"; print "\n" unless ($prev=$page-1)<1; print "\n" unless ($next=$page+1)>$#data; @chunks = split(/<%(.*?)%>/ms, $body); for ($i=0; $i<@chunks; $i+=2) { $chunks[$i] =~ s/&/&/msg; $chunks[$i] =~ s/\n/msg; $chunks[$i] =~ s/ /  /g; $chunks[$i] =~ s/^~~ (.*)/

\1<\/p>/mg; $chunks[$i] =~ s/^~ (.*)/

\1<\/div>/mg; $chunks[$i] =~ s/^! (.*)/

\1<\/p>/mg; $chunks[$i] =~ s/\*(\w.*?\w)\*/\1<\/b>/mg; $chunks[$i] =~ s/\[(\S*\.png)\]//g; $chunks[$i] =~ s/\[(\S*\.html?)\]/\1<\/a>/g; $chunks[$i] =~ s/\[(.*?) (\S*\.html?)\]/\1<\/a>/g; $chunks[$i] =~ s/\[(http:\S*) (.*?)\]/\2<\/a>/g; $chunks[$i] =~ s/\[:([^\n]*?):\]/\1<\/tt>/msg; $chunks[$i] =~ s/\[:(.*?):\]/

\1<\/pre>/msg;
  $chunks[$i] =~ s/\["(.*?)"\]/
\1<\/blockquote>/msg;
}
$body=join('',@chunks);

print "
$title
\n\n";
print "
\n";
$ul = 0;
$ol = 0;
$out = '';
foreach $line (split("\n",$body)) {

  ($stars,$line) = ($line =~ /(?:(\*+)\s*)?(.*)/);
  $out .= "\n
    \n" while $ul++length($stars);

  ($hashes,$line) = ($line =~ /(#*)(.*)/);
  $out .= "
      " while $ol++length($hashes);

  $out .= "
    1. " if $stars or $hashes;
  $line .= "
      \n
      ";
  $out .= "$line\n";
  $out .= "
      2. \n" if $stars or $hashes;
  $stars = $hashes = undef;
}
$out .= "
\n" while $ul-->0;
$out .= "\n" while $ol-->0;

$out =~ s/\n+/\n/g;
$out =~ s/(
\s*)+
    /\n
      /g;
$out =~ s/(
      \s*)+<\/li>/<\/li>/g;
$out =~ s/(
      \s*)+
      /\n
      /g;
$out =~ s/(
      \s*)+$//sg;
$out =~ s/\n+$//s;
print "$out\n
\n\n\n\n";

__DATA__
=== ===
=== ETCON 2004 ===
~ !Echo Wiki:
~ lessons learned
=== ETCON 2004 ===
~ !Echo BBS:
~ lessons learned
=== Background ===
Not that anyone here cares, but my [http://www.intertwingly.net/blog/ weblog] is 100% [http://validator.w3.org/check?uri=http%3A%2F%2Fwww.intertwingly.net%2Fblog%2F valid] and well formed [http://www.w3.org/TR/xhtml11/ XHTML 1.1].
...
As the author of his own [http://www.intertwingly.net/code/mombo weblogging software], and co-author of the [http://sf.net/projects/feedvalidator feedvalidator], I wanted to bring this level of rigor to
* how my weblog is stored
...
* how my weblog content is maintained
...
* how my weblog is syndicated
=== AWFLE ===
At the [http://www.jupiterevents.com/blog/spring03/ ClickZ Weblog Business Strategies Conference] I discovered, much to my surprise, that a few other people shared my interest.
...
So, I embarked on an [http://www.intertwingly.net/blog/1472.html Analysis of a Well-Formed Log Entry].
...
a.k.a. AWFLE.
...
on a wiki named [http://www.intertwingly.net/wiki/pie/FrontPage PIE].
=== Results ===
Within a week, the server running my weblog was seeing [http://www.luci.org/luci-discuss/200210/msg00055.html LoadAvg] values in the triple digits.
...
But I digress...
=== Wiki ===
A Wiki is a wonderful thing.  It presents a blank surface upon which anyone with the desire to do so to contribute.  There is a complete set of [http://www.usemod.com/cgi-bin/mb.pl?HowTo HowTo] instructions for operating a wiki, documented completely on a wiki, of course.
...

Of course, I knew *nothing* about any of this when I created the !Echo wiki.
=== Wiki ===
From a technological point of view, there isn't much to a wiki.  The primary requirement is to have some form of an "edit this page" button.  There even is a [http://c2.com/cgi/wiki?ShortestWikiContest contest] to see what the fewest lines of code required to implement a wiki is - entries over a hundred lines need not apply.
...

There are currently five entries with fewer than ten lines each.
...

The shortest are in Perl, of course.
=== Alignment ===
If you have a coherently aligned and focused community, a wiki can be a very powerful thing, allowing collaboration to proceed at an astounding pace.
...

If you have a community in imperfect alignment, a wiki will accurately reflect this state.  Given a group with a genuine desire to align, a wiki can provide a powerful and positive feedback loop.
...

But what happens when you have an unbounded community with divergent goals?
=== Wiki ===
[http://www.wikipedia.org/ Wikipedia] potentially has an unbounded number of participants with a well defined goal.
...

You would think that the activities to define a well formed log entry would be a simpler task?
...

An encyclopedia, however, is a very partitionable task.  One in which people generally recognize their area of expertise.
=== BikeShed ===
[http://www.unixguide.net/freebsd/faq/16.19.shtml Parkinson] shows how you can go into the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions.
...

While it seems that there are a large number of people with an opinion on date formats and mime types, there are an even larger number of people with an opinion on how to [http://www.intertwingly.net/wiki/pie/NameFinalVote name] a project.  Or on the process by which names are picked.
...

Pie begat Echo which began not-echo (a.k.a. necho) which begat Atom.
=== Wiki ===
The current "Atom" wiki now has nearly one thousand pages.  That's a lot of energy that has been expended, dissipated, or whatever.
...

What happened with the creation of this wiki was the bringing together of hundreds, if not thousands, of contributors; coupled with tens of thousands of onlookers, kibitsers, and naysayers.
...

And as I said previously, in a matter of days, my server almost completely unresponsive.
=== DayPop, BlogDex ===
Weblogs and wikis can cause a feedback loop.  The simple act of having a few dozen people register their support for the roadmap quickly resulted in thousands of page views and the roadmap page itself hitting highs in [http://www.daypop.com/top.htm daypop] and [http://blogdex.media.mit.edu/ blogdex].  This caused more people to view the page, making more people aware of the project, may of which signed up, perpetuating the cycle for weeks.

=== Spam ===
Which much of the "energy" that has been expended on the wiki has been positive, there have been a number of attempts to derail the process.
...
* Some are simply infantile, like an attempt to insert words like "gay" into text.  These are quickly cleaned up.
...
* There are a number of well intentioned people who apparently see their mission in life to prevent the group from making some horrific mistake that apparently only they can see.
...
* There have been a number deliberate attempts to derail the process
=== Lightning Rod ===
In addition to host, a role that I have played is one of lightning rod.  A number of hurtful and untrue things have been said about me, and the company I work for.
...

"A grounded metal rod placed high on a structure to prevent damage by conducting lightning to the ground."
...

Note the recurring theme of energy production, absorption, and dissipation...
=== Mailing lists ===
Much of the business of Atom has taken place on the atom-syntax mailing list, hosted by the IMC.  I have found a mailing list to be qualitatively different than a wiki.
...

On the plus side, forcing a conversation to be linear does add a bit of focus.  People can more easily follow the chain of reasoning.  On the negative side...

=== Flamebait ===
Mailing lists seem very prone to flamebait: statements which may very much be true but are expressed in a provocative way.  Some people seem to just have an inborn ability to attract flames.
...

The most effective strategy for flamebait is to simply ignore them.  Unfortunately, to be effective, this needs to be universally applied.
...

What's worse, is that most flamebaiters don't seem to realize what they are doing.

=== !bbs: part 1 ===



On a wiki, emotionally charged words tend to be quickly replaced with ones that more effectively make the point that is trying to be made without the distracting [http://dictionary.reference.com/search?q=histrionic histrionics].
=== PermaThread ===
Mailing lists can discuss a topic without coming to a firm conclusion.  Even when a conclusion is reached, it seemingly can be reopened at any time.  This can be frustrating.
* Example: I'd likse all entries to have a server generated timestamp (GMT) so that clients can tell if there is a modification, *and* a potentially user controllable subjective time ("2 in the morning").  This seems simple, but keeps getting revisited.
=== !bbs: part 2 ===



On a wiki, time is collapsed.  By necessity, contributions have to focus on some new point of view that has not been previously expressed.
=== Weblog ===
Weblogs have much of the same benefits as mailing lists, with a few additions:
...
* Weblog authors act as filters/valves.  Updates can be as seldom as a few times a week versus literally hundreds per day.
...
* Posts contain a dramatic increase in contextual information in the form of personal relevance and hypertext links
...
* It is much easier to route around flamebaiters
=== "SnapShots" ===
While a blog can present a view which has a manageable rate of change, a snapshot can literally stop time.
...
* This can be important to implementers who may not want to invest in implementing a changing spec
...
* It also is important for interop
=== Overall ===
When looking at the big picture, I find it helpful to apply metaphors from physics and engineering:
...
* Energy, Space, Time
...
* Mirror,  Focus, Feedback, Filter, Valve, Dissipation
=== On the other hand... ===
~ "If it weren't for people, this job would be easy"
=== Lesson 1: time counts ===
* The people you most want to contribute have the least amount of time to do so.
...
* Neither wikis nor mailing lists address these problem of dealing with an information firehose.
...
* Overall, the process needs to be long enough to allow everyone who wants to contribute the opportunity to do so.  Or, at least, to remove this as an excuse.
=== Lesson 2: Cultivate contributors ===
With a mix of people, what you inevitably get are:
* People who are ready, willing, and able to move the ball in a direction they consider forward.
...
* People who are only good at telling you what they *don't* want.
...
* People who drop in a requirements and then expect somebody *else* to run with it
...
* People who wait to be asked to contribute
=== Lesson 3: Use a mix of strategies ===
* Wikis as common workspaces.  Polls, and any discussions where there is a desire to "sign" ones name should be done on mailing lists.
* Mailing lists should be used for *new* discussions.  Revisiting and revising should be done on a wiki.
* Weblogs for summaries, progress reports, and to highlight areas of current focus
* Versioned specifications, test suites, and running code provide stability.
=== Where are we going? ===

=== Where are we going? ===
~ IETF!
=== Where are we going? ===
* A draft charter will be prepared in time to be informally discussed at the [http://www.ietf.org/meetings/IETF-59.html IETF meeting] is Seoul, Korea on the week of 29 February to 5 March
* Hopefully, the Working Group itself will be approved in March
* Most of the work will be done on mailing lists
* Ideally, a face to face meeting of the Working Group will be scheduled to coincide with the August 1-6 meeting of the IETF in San Diego
=== Questions? ===