 |
You asked for it! (Ok, maybe you didn't)
|
 |
 |
Saturday, September 6, 2003 |
The latest round of wiki api talk with Don Park has pushed me over the
limit in my tolerance for not having an adequate C++ blogger api
implementation. So I'm picking up the gauntlet. I don't
know if it will be appropriate for a wiki api template (what HAPPENED
to me in the last 36 hours?) but it will serve as a nice solid platform
for experimenting with alternative server and client semantics.
Get your wish list ideas in now. I intend to post an 0.0.1 header in about 2 hours.
UPDATE: FYI: The
first round is going to be the blogger 1.0 api. I just don't need
to bite off more than that right now. Besides, I really need to
be sold on the need for deeper semantics.
4:05:50 PM 
|
|
The last few rounds with Don Park went and got me all insomniacified again. God I love/hate it when that happens.
As I see it there are 3 discrete architectural subsystems in a wiki:
- Presentation: This
is the user interaction model and it's associated rules, etc. Is
it presenting in html, plain text (for editing, etc.) Or is it a
part of an interactive gui system using something like the truly
funkalicious rich editing control in Tk?
- Functional Rendering:
Do NOT confuse this with the above. This is the translation layer
between plain text and the 'renderable' primitives (the abstract syntax
tree.) Rules in here consist of things like "what constitutes a
wiki word" and the abstract translation of the cutsey little formatting
markup rules you see in wikiland (4 dashes on an otherwise empty line
translating to a hard-rule, etc.)
- Repository management:
Are your wiki pages kept on disk in the filesystem? In a
database? Are they webDAVed in? The "api" required to
manage these pages is remarkably thin, so any number of protocols and
storage systems serve the purpose perfectly.
Keeping these things distinct and even making them pluggable give all kinds of wonderful flexibility with real payback.
For now, how this relates to the conversation on developing a wiki api
is left to the ambitious reader. I am going to bed. More
tomorrow no doubt.
I have a really bad sinking feeling that this is only the barest beginnings of this conversation.
4:31:48 AM
|
|
Some folks are experimenting with using Wiki to build websites. I particularly like what Matt Haughey did with PHPWiki and a bit of CSS magic dust. Looks nice, eh? [Via Seb's Wikis are Ugly? post at Corante]
Janne Jalkanen's Wiki-based Weblog
is interesting too. Hmm. Maybe blog API(s) can be used for Wikis too.
That reminds me, shouldn't Wiki formatted text have their own MIME
type? Is there one? "text/wiki"? For now, different dialects of Wiki
formatting rules will have to be accounted for like
"text/wiki+moinmoin".
What are your thoughts about collaboration and locking as reflected in
the api? That to me seems to be one of the big tech hurdles
that'll have to be dealt with. Normally in wikis (or I should say
'currently') the page is edited and replaced as a whole. I
remember in the original wiki this started creating problems when the
user count got high. There was some deadlock in the usage model.
The existence of an api presents opportunities to really create a
problem with the current semantics of wiki interaction. The most
dramatic exposure is when scale (or misuse) cause clashes. I
played around with various permutations of wikis both homegrown and
d/led and when implemented as a CGI there are a few solid methods that,
at first glance, look like candidates for a straight mapping into an
api. At the core it's just:
- View: grab a page if it exists, render it as html and present it to the client
- Edit: grab the page content (if it exists, placeholder text
if it doesn't) and embed it in an html editing framework and present
THAT.
- Replace: given a page name and a block of raw content, replace the current version in the repository with the new version.
But I expect that's not quite robust enough for the stuff Don's talking
about, though I could be wrong (I figure it's about 50/50.)
There's something missing and I'm not quite sure what it is. In
the canonical wiki semantics the "edit" command locks a page with a
timeout from being edited, and the replace command unlocks it. So
it's not stateless in this form which creates a problem with the
web-services api approach.
Then again, it's really only a problem if you look at it as one.
Wiki was always sufficiently protected by backups to prevent any major
worries based on race condition and deadlock corruption issues.
One approach to the problem would be to split a wiki page into
micro-updates and handle them individually. But that constrains
the format to something frighteningly close to blogs.
Another is for "append only" conversational-style access. That
certainly solves the technical issues all at once, but it creates wikis
that really ARE irrevocably ugly. And it creates the same thing I
just mentioned, a partitioning constraint on the page content
itself. Blechh.
Data integrity and content spam becomes an issue when you have a
general purpose audience. Already the wave of comment-spam is
getting thick in the blogosphere. "True" popularization of wikis
will create an even greater exposure since content isn't append-only
(ignoring my ramblings above.) Even if it was there would still
need to be some form of revision control. But now it's starting
to get big. I suppose it's relatively dependent on how "complete"
an api oughta be. Would a standard wiki api need to exist
at a level where it could be used as the exclusive mode of access
through a service provider? (ala blogger?)
I can envision all kinds of whacked out page listing and cross-linking
semantics that I fear people would try to add, which is most of what my
hesitation comes from.
Rule #1... don't blog at 3 am.
2:41:04 AM
|
|
© 2003 Michael Wilson
Last Update: 10/26/03; 19:35:12
|
|
|
|
 |
| September 2003 |
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
1 |
2 |
3 |
4 |
5 |
6 |
| 7 |
8 |
9 |
10 |
11 |
12 |
13 |
| 14 |
15 |
16 |
17 |
18 |
19 |
20 |
| 21 |
22 |
23 |
24 |
25 |
26 |
27 |
| 28 |
29 |
30 |
|
|
|
|
| Apr Oct |
|
|
|
|
|
|