(This App now exists: http://wiki.colorstudy.net )

OtherWikisFeatures_ -- cool things found elsewhere that we should
steal^H^H^H^H^Hbe inspired by.

Zope has ZWiki, why don't we have a WikiKit? We could write one from
scratch or make a stub interface to one of the existing Python wikis
(Twiki is working well here; there's also PikiPiki_, MoinMoin_,
PikiePikie_, Pyle). Using an existing one would, of course, allow us
to leverage its features and development, but it requires kludging
since none of the existing wikis were intended to be embedded thus.
We could also tackle some existing problems in the wiki world, such as
providing an XML DTD as a common base format for converting one wiki
server's syntax to another's, and scripts for importing wiki data
to/from other server's data stores.

- MikeOrr_ - 07 Nov 2001 

If we go ahead and make this, the backend should be completely
independent of Webware. Only the interface should be tied to it.

Also, I prefer the names WebwareWiki_ and WWiki to WikiKit_, but
that's probably because I dislike the \*kit naming scheme as whole.

-- TavisRudd_ - 05 Nov 2001 

If you seperate out the concepts, it can be a more
managable/reusable/aproachable project.

For instance, there is the WikiSyntax_, which is similar to
StructuredText_ -- but it's only *societally* important to the Wiki,
not technically.  Some Wikis use straight HTML anyway.

Then there's the editing interface.  This is vaguely what I did in
ComfyEdit_ , which is more notable to say that part isn't that hard
either.  Most Wikis that aren't built on object databases of some sort
are actually just a set of text files that get edited.  TWiki is
clever enough to add RCS recording to that process as well -- but then
it's just a bunch of ``.txt`` and ``.txt,v`` files.

.. _ComfyEdit_: http://www.colorstudy.net/software/comfyedit

The third important part of a Wiki is the naming and linking
mechanism.  Personally, I like the notion of named links ala Wiki much
better than HREFs for internal links anyway.  The WikiName_ syntax can
be awkard, but the essential flat namespace could be mapped to from
different syntaxes -- that's more a text formating issue.

Each of these really has a lot of value on its own.  Easy text editing
is nice (maybe an appropriate format for WebwareDocumentation_ even).
Editing pages/files/objects is generally useful -- it could even be
considered a subset of something that includes FTP and WebDav_.  The
named links are also a very interesting linking idea (including
backlinks); it provides an interesting alternative to hierarchical
namespaces.

The lesson of WikiWiki_ isn't so much one of cool technologies -- it's
of putting together a set of useful ideas into something that is much
more than its parts.  There might be other combinations that lead to
other cool stuff -- if the parts are all orthogonal, we might stumble
on something great.

-- IanBicking_ - 07 Nov 2001

Here's some ideas for possible enhancements to existing Wikis such as
TWiki:

* firm up the StructuredText_ syntax (see
  http://structuredtext.sf.net)

* auto-syntax coloring of code listings (starting with Python, but
  extending to other langs)

* multi-topic search and replace tool

* make it possible to have `non-web interfaces`_, along the same lines as
  WebDav_.  Think of a WikiMode_ for Emacs! (already kind of
  possible, seeing as Emacs has a web browser and speaks HTTP)

* make it possible for the Wiki to understand several different
  WikiSyntax_ styles

* provide conversion and import tools, like Mike suggested above

* make the web interface prettier and more functional: 

  * edit-box that spans 90% of window width rather than a fixed width
    _(Not possible, as far as I know)_

  * provide a more functional WebChanges_ page, or simply use a
    WebCVS_ script

  * make the homepage of the Wiki prettier (TWiki's is rather ugly)
    _(Simply because I haven't changed the templates -- not really
    TWiki's fault)_

  * make it possible to roll-back changes (to an abritrary
    rev. number) _(You can do this in TWiki)_

* make it possible to use Subversion rather than CVS. _(Why? What is
  Subversion?)_

* extend TWiki's concept of 'webs' to allow nesting of 'webs' (like
  Python's package structure.  ... blends the flat namespace of
  traditional Wiki's with a hierarchical structure like Zope's
  folders.

* use something other than basic HTTP authentification for logging in.

* allow tight integration with the other AppIdeas_ that we've floated.
  In particular:

  * WebwareZope_ / WebwareSourceforge_ -- huge potential here! 
  * WebwareListArchive_ 
  * WebwareForum_ 
  * WebwareVaults_ 
  * PythonWebStats_
  * WebwareSlash_

* make it possible to embed editable regions in otherwise
  write-protected wiki pages (There's another Wiki that does this, but
  I can't remember which one)

* make it possible to view/preview the contents of one WikiTopic_
  inside another.  This would be enabled via either a button on each
  topic or a user setting.  The view/preview bit could be done
  in-place or via a separate frame (preferable).  Think of it like the
  view pane in an email client.  Each WikiName_ link would be followed
  by a * or some other symbol when this feature was active.  Clicking
  on the * would display the contents of that WikiName_ in the view
  frame.

* make it possible to use Templates (like Cheetah's object-orientated
  ones) for individual WikiTopics_.

* make it possible to drop in 'user interface components' such as
  ready built forms, surveys, etc. into a WikiTopic_

* make it possible to store custom meta-informational fields about
  WikiTopics_.

-- TavisRudd_ - 07 Nov 2001 _(IanBicking_)_