Re: [wikiss-users] Derivative work

[Adam Zivner <adam.zivner@xxxxxxxxx>]

Hi.

2009/6/20 Neven Boyanov <boyanov@xxxxxxx>:
> Hi All,
>
> I'm glad to hear that you are interested in such work.
>
> Here are some of the goals ...
>
> The format of the data should be kept simple - one file per page, page name
> the same as page file, the content of the file still readable without the
> wiki text renderer. We'd like to have the information written in the text
> files to be available forever, regardless of what's the next programing
> language or what is the operating system or what the databases will be in 20
> years. That's why we chose flat-file based system.
>
> We keep most of our organization's projects' documentation in plain text
> format but also would like to see them nicely presented on a web page, so
> wiki is good for that.
>
> One of the ideas is that the pages' store could be put in a version control,
> such as CVS, and this way keep multiple locations (almost) always in sync..
>
> Example:
> I can work off-line on some pages or documents, let's say writing
> documentation for a software project or doing research and taking notes,
> later I will commit those change in the version control which in its turn
> will trigger update on a website ran by this wiki and this way the updated
> text will automatically appear on the public website.

Why not to read/write files right from/into the RCS? Of course, it's
not so "flat" because you need some client and server to read the
files, but otherwise you'd need to synchronize changes between RCS and
files which is generally quite difficult (what happens when RCS stops
working etc.)

> Another goal: an improved and well developed plugin architecture, yet
> simple, so most of the new functionality could be moved in plugins.
>
> Plugins implemented so far:
> * Blog - allows to add blogs by date specifying a subject. The pages' files
> could be kept in separate folder to keep the main folder clean. To each blog
> entry could be added comments.
> * Comments - allows to write comments for pages, including blog entries.
> There is Captcha added for Spam protection. Comment pages could be kept in
> separate folder (not finished yet) to keep the main folder clean.
> * TOC - allows to structure the document by using headings and later
> generate a table of contents that could be shown at the top of the rendered
> page. This is rather improvement of the existing TOC code and moving it to a
> plugin.
>
> The pages for comments and blogs could be kept at different location/folder
> so the pages' storage will remain clean of unnecessary files. This is done
> through plugin specific configuration files.
>

Although I understand your point, I'd suggest an alternative. I think
that blogposts and comments are essentially the same think as wiki
pages:
- unstructured texts
- they have main text, subject (title), datum of creation
- all of them can be versioned
So, blogposts and comments could be treated (edited, saved) just like
normal pages, the only difference could be in their presentation
(view). This could lead to daramatic simplification of the plugin and
would maintain backward compatibility - i.e. blogposts and comments
would be still readable even when blog plugin would not be installed.

This is connected to the idea to have more structured file hierarchy,
or we can call them "namespaces". "Ordinary" pages would be kept in
main namespace, i.e. "root" directory:
/
Blogposts would be kept in "blog" namespace:
/blog
Comments would be kept in namespace of the corresponding blogpost
/blog/My birthday party/comments/
etc.

> Modules are like plugins but they provide only functionality, they do not
> modify the content. There is only one module implemented so far:
> * Captcha - provides all necessary functionality to add captchas to the
> Comments plugin.
>

Is their any real distinction between plugins and modules or is it
just matter of clasification?

> Other improvements: the most important entities in the system were put in
> classes; added more comments in the code (in English).
>
> Some work in progress:
> * Zones - break the wiki site into different areas for different purposes -
> let's say development, based on region or even for different languages for
> multilingual websites.

This could be easily doable with "namespace" directory structure
approach mentioned above.

> * WYSIWYG text editor - very simple with basic functionality.

I'd love to see something like this. Do you plan to create your own or
base it on some existing solutions? Most existing solutions have
output only to HTML and are not easily modifiable to output wiki
syntax (one exception is http://mediawiki.fckeditor.net/). This is
even more problematic with the following point.

> * Renderer - the wiki format rendering should be put in a module/plugin,
> should be documented too.
> * Tables - that should be a plugin that will visualize CSV data, either from
> a file or inline.
> * Localization - should be implemented as a plugin or module,
> constants/variables should be used instead of strings.
> * Authentication - should be with username/password. May be in the future
> add list of user, not just one.
>
> I don't know if it is good idea to send the source in this mailing list
> (anyone disagrees?) but we intend to run a separate website where everyone
> could download it. I'm going to register a SF.net project for that purpose,
> with publicly available version control too.

I'm not sure if it's a good idea but I'm quite sure it's not a bad
idea :) (basically why not?).

>
> I just wanted to know if anyone involved in the previous works (Tiger,
> Wikiss, etc.) has any objections.

Both authors of TigerWiki and WiKiss are inactive for some time and I
couldn't manage to contact them either.

>
> Regards,
> Neven.
>

-- 
S pozdravem Adam Živnéř | ICQ: 354-750-968 | Mobil: 775 610 300

---
http://wikiss.tuxfamily.org