Dave Johnson on open web technologies, social software and Java
Apache JSPWiki Manifesto: This idea has been brought up before, but so far it has not really been an issue. However, this looks like the time when it would be possible to accomplish this.
JSPWiki code base is old, and it needs some refactoring. This refactoring includes things like moving to Java 5, fixing the metadata engine, replacing the backend with something scalable, and in general removing all the cruft that has been accumulated over time. This requires that we break compatibility with existing plugins and other components. Not badly, but to some degree.
Also, JSPWiki as an open source software project is growing slowly but steadily. However, the wiki world is moving rapidly, and wikis have been adopted widely. JSPWiki has become a tool for a great many companies, who are relying on it in their daily business. This is a lot for a hobby project lead by a "benevolent dictator" -model. Therefore, it is time for JSPWiki to mature to a "real" open source software project to be a serious contender in the wiki world.
To accomplish both of these goals needs a major shift in how JSPWiki is managed and who "owns" it, in a sense. Therefore, we (the people who have been committing source code) think that Apache would be a good choice, and have decided that we will try to submit JSPWiki into the Apache incubation process, with the goal of graduating as a top-level project.
I've been a JSPWiki (and Janne Jalkanen) fan for years now. It's my favorite Java-based wiki so I'm pretty excited that the dev team is preparing a proposal to move the project to Apache. I think this will be a great move and will ensure that the project continues to grow and continues to be a strong contender in the enterprise wiki space. I'm more than willing to help with that proposal and to help out in the Incubator.
I spent Friday and Saturday in Greensboro, NC at the ConvergeSouth 2005 conference. I had a great time meeting fellow NC bloggers and attending talks on community building, blogging and journalism, collaboration, blog tools and podcasting. The next couple of posts will be my trip report, based on my notes and recollections. This is final installment #3 of 3.
Saturday, the focus of the ConvergeSouth conference was new media and "creativity on the web for all people" and the format was Dave Winer blogcon style "un-conference." That means there's a moderator with no prepared talk or slides who briefly introduces a topic and then the audience engages in a blog-like conversation on the topic. Interesting idea and it can work well, but I still like the old tried-and-true "expert gives engaging, insightful and interesting talk" format of conference and fortunately some of the speakers at Converge did too.
Policing the Media, Duncan Black
The first talk I attended was Policing the Media led by Duncan Black. After a fairly long introduction, he went into the blogcon format. In his introduction Duncan explained that he wants to improve the media. We deserve better. He had a litany of complaints and didn't try to capture them all. Traditional (and I'm assuming he means print) journalists ignore the rest of the media: talk radio, cable news networks, and partisan news outlets. Journalists won't admit mistakes. They don't do proper fact checking.
After his intro, Duncan didn't really get any objections from the audience and in fact the first question was from a newspaper guy who asked how papers can collaborate with bloggers. Some suggestions were to use bloggers as stringers, to use hyperlinks, and to look at what The Raleigh News and Observer is doing with its blogs and specifically Tarheel Blogwatch. From there the conversation moved to stories of policing the media, the most memorable one involved the issue of hot topic voting machines. I must say, the blogcon format worked pretty well for this talk.
Collaboration, Jimmy Wales
The next talk was on collaboration by Jimmy Wikipedia Wales. It was a traditional presentation, not blogcon format, a complete history and status report on Wikipedia and closely related projects like WikiNews and Wiktionary.
I was most interested in the discussion of real time peer review and the techniques used to keep the wiki vandals and spammers at bay. The Wikipedia folks are able to correct damage and ban the attacker within a minute of an attack. That's great, but is pretty depressing how many people they have working on "recent changes patrol." That's why I keep the Roller wiki locked down and only give username/password access to people I know. Jimmy mentioned the need for a global blacklist of spammers and vandals and that Wikipedia is the logical place to maintain such a blacklist. Roller really needs a good blacklist (for comment/trackback spam), especially now that Jay Allen has stopped maintaining MT-Blacklist.
Tools & the Future, Dave Winer
This was an open blogcon style session centered on the question what do you want from the tools. Much of the discussion was dominated by a couple of complete newbies who just wanted things to be easier, but didn't have any concrete suggestions. That's fine I guess. It confirms what I think most folks working on blogging tools already know: ease of use and simplification are the top-priority (well, ok, maybe they come second to spam-prevention). Here are the most useful suggestions that I heard during the session.
I don't think the blogcon format worked very well in this session. We would all have benefitted from a little better preparation and a little more steering. See also: Kevin Howarth's notes from this session.
Podcasting, Herb Everett
This session was a basic overview of podcasting. While it was interesting to hear Herb's experiences, I really didn't learn anything that I didn't already know about podcasting. Talking to some podcasters after the session I learned that the Apple iTunes tags are pretty important nowadays (but have the bugs been worked out?). I'm wondering if Roller's podcast support should include them in addition to the standard <enclosure> tag. See also: Kevin Howarth's notes from this session.
Dinner and conclusion
Saturday night, I attended one of the hosted dinners and finally got to meet Ed Cone, Greensboro blogger and one of the conference organizers. I've been reading Ed's blog ever since I discovered his Jerry Garcia interviews a couple of years back. Ed interviewed Jonathan Schwartz and Tim Bray just the other week, but didn't realize that blogs.sun.com is driven by homegrown North Carolina software.
That's it for my trip report. All and all a great experience. If you want to read more about the conference, check out conference organizer Sue Polinsky's list of posts on the topic and the Technorati tag ConvergeSouth.
First google result for: standard wiki syntax
Is "no standard syntax" really a good thing? When the wiki itself is the user interface, perhaps it is, but if you want the user interface to be a slick WYSIWYG desktop client that edits any wiki via Atom, then having a different syntax for each wiki really sucks.
Newsfeed search engines like Technorati, Feedster, and PubSub make
it easy to monitor blogs and news sites. You can subscribe to a search
newsfeed to be alerted whenever a blog entry or news items matches your
search criteria. But how do you monitor all of the wikis of the world?
The newsfeed search engines don't monitor wiki recent changes
newsfeeds, or do they?
Tim Bray wonders why somebody would assert that blogs and wikis are converging because "in their essential nature, it seems like they couldn’t be more different."
Danny Ayers responds that "it’s not that they’re 'converging' it’s that they’re fundamentally the same kind of system."
My opinion? Blogs and wikis are similar in that they both aim to make it easy to "write the web" and as web systems, they both can benefit from many of the same technologies/features such as syndication, referers, trackbacks, WYSIWYG editors, etc. At the same time, they are different in essential nature, as Tim points out, but they differ in complementary ways -- and that's why they go so well together.
Blogs and wikis are merging. The evidence to support this assertion is the growing popularity of blikis or wikiblogs which include both blog and wiki capabilities. Some of these are wikis with blog features grafted on, some of them are blogs with wiki integration features, and some that are (or appear to be) designed from the ground up to be combined systems. Danny points out Bill Sietz's Wikilog and Martin Fowler's Bliki, but there are many more examples of combined wiki and blog systems.
BTW, I've written about this before.
Microsoft flexes more open-source muscle | CNET News.com: "FlexWiki is the third piece of Microsoft code that the company has released this year under an open-source license, all under the Common Public License (CPL). In April, Microsoft posted its Windows Installer XML (WiX) to SourceForge.net, following up a month later with the posting of the Windows Template Library (WTL) project."
Wiki syntax seems to be working just fine in Roller 0.9.9 as demonstrated by this fine quality Wiki-Blog post.
I'm not sure why your _entry page template is not working, Matt. Perhaps one of the macros you are using has a different call signature than it did in 0.9.8?
The good news is that, with Lance's improvements to the plugin pipeline, you no longer need that _entry page template to enable Wiki syntax. If you have the Wiki plugin listed in your web.xml and you have the Wiki Syntax checkbox checked on your Website:Settings page then you will see a Wiki Syntax checkbox in the Weblog Edit page. You can enable Wiki Syntax on a per Weblog entry basis by setting that checkbox.
By the way, Wiki support is not enabled on JRoller.com because there is no Wiki on JRoller.com.
I've been doing a little informal research into Wiki software options and Wiki APIs. I'm trying to understand the state of the Wiki software market, if you can call it that, and especially the state of Wiki APIs. This post is a summary of what I have learned so far.
Where we are
Where we could be
Unfortunately, the list of Wikis that don't support the WikiRpcInterface is a lot longer than the list of those that do. For example, the popular open-source Java-based SnipSnap Wikiblog doesn't support it and neither does the Atlassian's new closed-source Java-based Wiki Confluence. SnipSnap provides no Wiki API at all. Confluence, on the other hand, supports an extensive API in both XML-RPC and SOAP-RPC flavors. With the Confluence API you can:
That's a pretty impressive list of capabilties and it has already inspired a slick GUI client called TimTam. Take a look at the cool screenshots. It's really a pity that TimTam only works with one Wiki - and a payware one at that.
A side note: I wanted to find out more about Wiki API support in the closed-source Socialtext Wiki/Weblog product line, but the Socialtext website is not very sociable. I could not find any detailed product information, documentation, or developer information on the site. They don't even have site search. I'm not ready to register for a free demo or marketing spam yet, so I'll look into Socialtext at a later time.
The way forward?
Recently, Joe Gregorio published an article called An Atom Powered Wiki. Joe showed how to add Atom API support to a simple Wiki. Joe's example API is very simple, only allowing getting, putting, and deleting Wiki pages but, because Atom is exensible, and in a SOAP compatible way, the Atom API could easily serve as the basis for a new standard Wiki API.
This is a test of the RollerWikiPlugin, Roller's new JSPWiki powered Wiki plugin. I upgraded this site to Roller 0.9.8-dev this morning and the Wiki plugin is working great, check that link for a little user/setup guide.
bold and italics and external links
what about inline images?
Yes, everything seems to be working.
Here is the weblog entry text for this post:
This is a test of the RollerWikiPlugin. I upgraded this site to Roller 0.9.8-dev this morning and the Wiki plugin is working great, check that links for a little user/setup guide. If you read that, you'll understand why the comments link is missing from this post. !!!Heading 2 !!Heading 3 !Heading 4 * item 1 * item 2 ** subitem 2.1 ** subitem 2.2 * item 3 __bold__ and ''italics'' and [external links|http://rollerweblogger.org] what about inline images: [http://www.rollerweblogger.org/resources/roller/leo5mo-sm.jpg] Yes, everything seems to be working.
Patrick posts about Wiki-blog integration and wonders how Wiki-blog integration plays into the future direction of Roller. Here are my thoughts on that. Roller is first and foremost a weblogging system. I don't want to incorporate a Wiki into Roller, and I think the other Roller developers agree with this, but I do want to make it possible to integrate Roller with an external Wiki.
For now, Wiki-Roller integration means allowing weblog entries to be authored using Wiki syntax, making Wiki links in weblog entries link to an external Wiki, and allowing each weblog entry to have it's own Wiki link to an external Wiki, as Patrick describes.
I'm doing this integration by adding an (optional) Wiki plugin to Roller. I use JSPWiki for the Roller Wiki, so I'm creating the plugin using JSPWiki. I have this working now on my homebox (without code changes to JSPWiki), next, I'll create a Wiki-blog demo here on this site so you can see how it works.
I spent some time today hooking the Radeox Wiki engine into Roller so that weblog entries may be authored using Wiki syntax. This was amazingly easy to do, but I've got a ways to go before it is really useful. For example, I'd like to be able to tell the plugin where my Wiki is and then have it treat all CamelCase words in my posts as links into that Wiki. Since my Wiki is JSPWiki-based, I guess I'd have to do more than just telling the plugin where my Wiki is located. I'd also have to tell it how to form Wiki page URLs.