Mark A. Hershberger writes:
> What a coincidence! I write on my weblog by typing text in emacs and
> typing C-c C-c! (weblogger.el is my secret weapon.)

:-)

Since there's been an overwhelming demand for a blog, and since this
list has been getting more noise than signal lately (those buggers
registered a bunch of addresses a while ago, and are using them. I'm
tempted to kill all .in and .cn addresses in attempt to stop the
blight, but I digress...), I'll write a bit more about a recent bOP
change. FYI, I am writing this as much for bivions as for the OSS
community, just like I write code for my customers as much as for the
programming community...

I added a Wiki (per a customer request, of course :-) to bOP this
week. I also added a feature that allows our customer to use the Wiki
to write help text. WikiView.pm outputs XHTML, and the customer can
control the L&F by adding a base.css to the wiki directory. And yes,
as with everything in bOP, each Realm can have its own Wiki.

In the process of creating the Wiki, I was trying to figure out why
blogs, wikis, etc. are interesting. They are all CMS technologies and
they compete with each other. In bOP, they work together. To create
a blog, all you'd have to do is render the RealmFiles in a Table
ordered by date with WikiView. A blog is a chronological wiki. A
wiki is a blog with clear and uniform naming.

The way I see it, Wikis, blogs, html, etc. are an attempt at
decoupling the content from the presentation. It's a problem the
software industry has been repeatedly solving since at least the
1960s. It's really not that complex a problem -- hence the
re-inventions. It seems to me that programmers like solving simple
problems with complex solutions, because it's too hard to actually
write and re-use good abstractions. It's one of the reasons why CSS
is so messed up even though there were innumerable better solutions to
the problem of decoupling formatting from content prior to the
invention of CSS, but I digress again...

Why did I write my own wiki? Blogs and wikis get one thing wrong that
bOP gets right: groupware. They focus on the content creation and
naming, which is a trival problem, and they often do a bad job at it
imiho. weblogger.el seems like an odd mix of bad ideas, too. Why
does it use XML-RPC, when WebDAV has been around longer and is
supported by more web servers?

The two problems CMSes solve that general groupware systems don't
solve: naming and formatting. Groupware sometimes handles formatting,
but the point of groupware is to solve the
security-for-shared-resources problem. In other words, good groupware
gives the appropriate access to files and other communications to
people in a group. The formatting problem is something that you throw
on top of groupware, because people do need to format their content
every now and then. CMSes also handle versioning, but that's not the
topic I'd like to talk about today, and it really is distinct from
naming and formatting.

Assuming you've solved the file access problem, you'll use those
abstractions for the Wiki so all I have to think about is naming and
formatting. Naming in Wikis is just fine. CamelCase works, and I
just used that. You also want to match email addresses, domain names,
and local file references, and so one. In our wiki, you refer to an
image in the wiki folder by naming it, e.g mypicture.jpg. The wiki
formatter turns it into an <img> link just as it turns emails into
mailto's. (This is a private wiki so we don't care about hiding
addresses, and if we needed to, we could make the mailto: be a local
form email so the address doesn't get public.)

The general formatting problem is interesting. Just like this email,
I use blank lines for paragraph delimiters. I also allowed _italics_
and *bold*, but that's it. I didn't want to invent my own formatting
language, and I wanted to keep the essence of a wiki which is: it's
the content stupid. If you want to format, use HTML, Illustrator, or
TeX.

I tried to avoid the introduction of syntax for names of things,
because an interpreter can easily discern between the many types of
external objects we need to name and ordinary natural language.

I do know my customer wants bulleted lists, and a few other things
like strikeout and underline. I also know that with a collaborative
mechanism, there would be a price to pay if the syntax was not easily
usable by experts in HTML, and at the same time, understood by
people who don't like matching up angle brackets and tags so here's
what I came up with:

@ul
@li The syntax uses html tags so I didn't invent the names.
@li Similar tags close each other like good ole HTML 1.0.
@li Tags must begin at the start of a line so @perlvar is not treated specially.
@li
Only formatting tags were included, not @form, and @script,
This wiki is about content, which can be inserted in places,
and can link to the main HelpWikiHelp.
@ul

The wiki interpretation code is in a single 280 line module:

http://www.bivio.biz/f/bOP/lib/Bivio/Type/WikiText.pm

And since this an XP lists, here's the unit test:

http://www.bivio.biz/f/bOP/tests/Bivio/Type/t/WikiText.bunit

I hope those of you have read this far have found this useful. It's
the type of stuff that doesn't appear in code, and shouldn't. It's
not the type of stuff I can spend my time on, because I'm a much
better coder, and I strongly believe programmers learn the most by
trying to figure out abstractions rather than reading about them.
However, I thought I'd try this for a change and see what feedback I
get. :-)

Rob