Moving this to tools-yak as that seems the right place for it. (01)
On Mon, 1 Dec 2003, Bill Seitz wrote: (02)
> Very cool. (03)
Thanks, always nice to get some feedback. (04)
> * Arts documents are static HTML files, right? Have you considered
> pushing them right into wiki? (05)
The original Arts (blackarts) wrapped email messages in an HTML
document with some metadata. The message was stuck in <pre> tags. (06)
Here's (07)
http://www.burningchrome.com:8000/~cdent/fiaarts/ (08)
a sample of that style. (09)
The latest Arts (not (yet?) released) writes text files that are
in the purplewiki wikitext format. I decided not to push them
right into the wiki for a few different reasons: (010)
* I had code already for the apache handler and I wanted to get
this going quickly. (011)
* I'm toying with the notion of moving away from wiki databases
that contain content, but instead contain pointers to files. To
me this expands the editing and manipulation possibilities. (012)
* I wanted the categorization and ordered by modification and
creation time contents lists that Arts provides. (013)
* Arts is associated with a tool called Webwatcher that looks for
expired files and notifies the owner that they need to do some
maintenance. Having the files on the filesystem is necessary
for webwatcher. (014)
* I'm in an environment where people like to use their particular
editor on a unix machine, not a textarea in a browser or an
editor associated with those things, not an editor that pulls
text from the wiki. These are people who want to be able to
grep, ls, sed and otherwise fiddle with stuff. And I like that. (015)
I am doing straight into the wiki for my WikiPiki stuff: (016)
http://www.burningchrome.com:8000/~cdent/wiki.cgi?WikiPiki (017)
> Is the standard practice to (a) recognize
> that something belongs in the repository, and (b) write accordingly
> (provide some context, make the message/document rather general, etc.)? (018)
In the environment where Arts was written the process evolved
from this: (019)
* Someone (a) is working on a project and they write a description of
some hurdle they crossed or solution they discovered to the
group mail list. (020)
* Someone else reads that and responds with "Blackarts?" (021)
* (a) bounces the original message into Arts through its email
gateway (022)
* (a) Then goes and cleans up the file to make it more general,
either right then and there, or within 15 days. If 15 days pass
they are harassed by Webwatcher to doctor the file. (023)
>From there things evolved to include project specifications and
documentation. It is in that vein that this new version is being
used, along with storing fairly static documents. (024)
All of this could be accomplished in the wiki, but we've found
the email -> filesystem thing works out pretty well for things
that need only occassional maintenance and/or need a sense of
authoritative categorization (specifications go in the Specs
category, for example). (025)
The associated Wiki tends to contain stuff that is a bit less
document oriented, changes more often, or is a bit more
speculative. The Arts repository is used to say to managers,
"here this is what we are doing" while the wiki is used as more
of a scratchpad. (026)
We try to avoid things needing to be written. Writing is
happening all the time so we try to get that writing useful. (027)
> * It's worth remembering that there is no One "wikitext". I notice that
> the BlueOxen wiki is based on UseMod but has some variants from its
> wikitext rules. Are those differences significant? (028)
There is only one true wikitext and that is the one Eugene and I
came up with! :) (029)
Yeah, this is definitely worth noting. I'm not sure what to do
about it as there seems to be a great deal of religion associated
with it. I like our simplified UseMod style because it is simple
and, most importantly, it is easy to make links. I stumble in
other formats. (030)
If by significant you mean was there some motive in their
removal, yes, a bit. Two forces came into play when doing the
parser rewrite: (031)
* How hard was the feature to do while still being able to purple
"things" effectively. Eugene may have more on this as he did
most of this part. (032)
* Did the feature fit in with a not well described ethic on what
ought to be on a wiki page. This killed things like tables and
horizontal rules. Table formatting in wikis is almost as hairy
as table formatting in HTML, so that seems to defeat the
purpose. <hr>s perform a structural dividing function that
seems better served by actual structure. hr is actually
presentational fluff. PurpleWiki parses to a tree of Structural
and Inline nodes. (033)
But I may be remembering it wrong, that particular moment in
history was quite chaotic. So, Eugene? (034)
> * is that IRC bot "paulb"? I just checked the BlueOxen IRC channel and
> it wasn't running. Eek, there's no wiki page for it? Have you played
> with JoiBot? (035)
What we've got going is klogger, who is a descendant of paulb,
who is a descendant of frogger. Frogger was used in the Helium
project that I've mentioned before. A Matt Liggett production. (036)
Back when I put up paulb we didn't seem to generate enough
interest to invest the time in making his presence secure. Since
then real life has called me away. (037)
I'm going to respond to John's message with some coments on how
klogger works and the code, since he was looking for some recipes. (038)
klogger improves on its predecessors by getting rid of the need
for cron jobs, adding a configuration file (so you can have one
script running multiple times on different channels), and doing
better message passing when a new user connects. (039)
I've not played with JoiBot but various people have told me it is
pretty cool. My experience with IRC is quite limited: I've only
used it in the very limited sense of a communication device for a
working team. Purpling the logs makes for happiness in such
situations. (040)
--
Chris Dent cdent@blueoxen.org
Once you knew, once you really, really knew,
then you had lost your alibi. --Samantha Power (041)
--
This message is archived at: (042)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=Pine.OSX.4.53.0312011733230.3791@d-18-169.dhcp-129-79.indiana.edu (043)
|