Izumi: Ralf - What Is Izumi
Index: Home     | What Is Izumi | Misc Links   | Random Thoughts | Too Much To Read | The Rant Vault | Quotes
Dev:   Projects | Ideas For Dev | Nerdkill | Rig | Hint


Description of what 泉 Izumi is all about. Sort of.

See also: Izumi Text Syntax
Note: this page uses UTF-8 encoding in order to properly display Japanese characters.
Site License And Disclaimer as well as contact information are available here.
$Id: What Is Izumi.izu,v 1.15 2005/11/05 21:55:57 ralf Exp $

1. Summary

Title: Izumi (泉)
Goal: Simple web site content management using formated text files

Acronym: IZU
Language: PHP
Environment: Linux/Apache/PHP or Win2k/IIS/PHP
Type: Web script

Started: 2003/08/08

2. Description

1.2. Purpose

Izumi is a simple web site content management. Each page is rendered from a text file with a syntax similar to Wiki's text input or Textile. Rendered pages are rendered as HTML; this HTML is cached on disk when viewed the first time in order to make subsequent views fast & low on CPU.

It is possible to update the text files directly on the server, using any kind of text editor.

There are features not supported by this project:

I envisionned for the system but decided against it. They would add complexity that I do not need. When this project becomes open source, I'll see what users want and adapt.

Originally I was planning to submit the project to SourceForge using the RIG license (Perl's Artistic license). Then I decided I would merge it in RIG and that it had no future as a standalone project. Now I'm changing my mind again. It would be good to merge it in RIG, yet it is a useful project just by itself. The current architecture is pretty clean and most of the code specific to Izumi is splitted in a couple of classes or files, so it would be easy to share this part of the source between Izumi and RIG. More info later here.

Some of the descriptions here relates to my initial view of the project and have been more or less updated and thus may be inacurate now. I will keep it for history and later reference, but it needs to be cleaned.

1.3. Features

This section describes the actual features of the project.

<tbd>

3. Name

When looking for a name, I started with there initial ideas:

The first idea for a name was RTG (Ralf Text Generator). But then I decided to go for a Japanese-looking word (made up and sounding good) that conveys the meaning of bunch of pages with word content.

Tanigo was my first choice. It didn't sound that good. It was composed of tani (valley) and go (word), the valley as the entrance to a mountain of words.
Izumi sounded nice, goizumi or izumigo's not so good.
Izumikoto and kotoizumi were interesting altneratives (I believe the sound "goto" is an alternative to "koto").

"Izumi" sounds right; 泉 is a nice kanji; "fountain" is a good meaning. More precisely, it means a natural spring of pure water. A good 3-letter acronym is "izu".

4. Background References

4.1. Rationale

Why a new project? Why am I reinventing the wheel?

Like for most developments, it's easy to handcraft a fast prototype in "5 mn" (programmer's time), but it's more difficult to keep it alive and maintain it for real. The experience from RIG (and somehow from PowerPulsar too) shows that this actually happens if I actually use the project for myself and others. That and starting with a small goal to enhance it later rather than do the Right Thing first (a.k.a. Worse is Better).

4.2. Links & References

Probably none of the following will be used:

4.3. New links - 20030607

4.4. Text parsing - 20030830

I'm still trying to find an existing text parser to use (instead of hacking my own, which I started anyway). Here's a collection of related links (none providing the ultimate php script ready for me):

Having a look at the PhpWiki sources raises another issue: it is GPL, whereas I favor the Perl Artistic license. If my understanding of GPL is correct, reusing these sources imply I should make mine GPL too (and not just OSL compliant). That makes it a no-go.

Hmm I should add that my text parser currently is a big PHP/regexp kludge. I so don't like it as I can foresee it will be hard to evolve and maintain. Maybe there's a reason why PhpWiki's one is complicated.

20040423 Update: Actually my kludge is not so bad. It does a pretty good number of things. The only thing I currently lack is tables support, not because I couldn't code it but more because I fail to find a good wiki-like text syntax for tables.

5. Obsolete Ideas

These are old interesting ideas and extensions that I came up with when I started the project. They were useful in definition the direction of this project and highlight the kind of use I was envisionning. None of these have been implemented exactly as-is, if at all.

5.1. 20030808

Syntax can be Wiki, simplified and/or enhanced.

Workflow:

Backups/alternates:

HTML caching:

Reuse pieces of RIG or apply to RIG later:

5.2. 20030830

More ideas, en vrac:

Oh, I get it! Rather than have [topic:] I should use "number.number. + tab + title" for automatic heading generation.

There are two kind of templates:

6. Milestone 1

Started:  August 2003
Finished: November 2003
Status:   Closed

6.1. Description

Milestone 1 is a proof of concept, a pure hacked-to-the-core prototype. I basically took the PHP skeleton from RIG and made some classes to handle text files and display them.

The text rendering handles basic elements as links, hr bars, blockquotes, preformated text and first-level lists. That's really not much but it gives a good starting point.

6.2. Implementation

The source reuses the common files from RIG, which provide a bunch of utility functions to manipulate preferences, cookies, generate HTML parts, etc.

The main difference with RIG source is that this one uses PHP classes, to be exact the following classes were introduced:

6.3. Feedback

Izumi seems to be the right project. I currently edit this text file on the Linux server via Samba, using my favorite text editor on my Windows box. And I can see the result instantly by just refreshing Mozilla. That's the kind of workflow I had in mind and I like it a lot better than having to use a web interface to edit the page, as in PhpWiki, or use a form to enter a new blog entry as in Drupal -- less clicking, more typing. Just perfect, don't touch it!

Now, as far as the implementation goes, I'm not too sure what I want. The idea started with SyntheticPlan should be merged with Izumi. OK let's be frank: SyntheticPlan is not intended to do what Izumi does, but my idea was to have it "enhanced" (the real word is "hacked") to do something similar. Editing would probably have been done using a WinForm/C# desktop client that a simple text editor. Implementation wise, SyntheticPlan was also the first project that I wanted to plan and document thoroughly before writing code. So far that hasn't been too succesful either because I do have some valid doc but I have nothing to use -- thus no incentive to really think about it. So now I'm kind of considering going the other way around.

6.4. Result

Milestone 1 was a quick-hack prototype. It worked. You're browsing the result of a successful prototype right now :-) This is an attempt to update what has been done and what's left to do.

7. Milestone 2

Started:  November 2003
Finished: November-December 2004
Status:   Not-Quite-Closed (maintenance only)

7.1. Description

Milestone 2 introduces "blog" support in Izumi -- a given izumi file is automatically split in blog entries, the more recents are served and the older ones are accessible as "archives".

RSS support as been added.

As the project seems near completion now, Izumi will be labelled as version 1 and packages will be made available.

7.2. Implementation & Notes

Most notes have been moved out of the project page and into the Izumi page. Here you will find just a generic overview of the milestone 2.

(Notes are in chronological order.)

«»  2004/11/21 «» RBlog  «»

Implementation of the blog is pretty simple: a RBlog class is introduced, which is activated by a given Izumi tag in the Izumi master file. This class is responsible for splitting the master file into blog entries and blog archives, each one being a single Izumi file which are then rendered using the standard RPage class.

«»  2004/12/24 «» Overview  «»

The original idea was to merge Izumi in RIG 2.0 as a module and then implement blog support as a new additional RIG module. Since I kind of gave up on implementing the modular RIG right away, I decided instead to implement the "simple" blog idea I had earlier -- simply parse Izumi files and generate blog entries depending on a tag.

Having implemented just this, it works very well, doesn't feel too much like an ugly hack so far and the final code is pretty clean.

I started implementing a Debian package. Some RPM packages will follow although I'm not quite sure which platforms to start with.

Originally I also wanted a mechanism to remotely update the content base. Well I found the easiest way to go is simply use CVS and on the server have a cron job that does a CVS update every few hours.

No milestone 3 is planned at this point. I'll leave this running on my server for a while and eventually will add some minor feature and when I'll be satisfied the whole thing will become a version 1.0. I expect this to happen by end of spring 2005.

7.4. Result

Milestone 2 is very solid.

The blog implementation is clean and really adds a lot to the CMS part.

No milestone 3 is planned at this point. Milestone 2 should result in version 1.0.


end
R/


Site License

Creative Commons License
This work is licensed by Raphaël Moll under a Creative Commons License.

Options
Color Theme: Gray  | Blue  | Black | Sand  | Khaki  | Egg  | None

Web ralf.alfray.com Powered by Google

Display Izumi & PHP Credits

Stats
4266 accesses, 1 access from 54.196.196.108
Visited 91 times by Google, last 2014/06/28 13:44
Visited 63 times by Yahoo!, last 2014/07/21 01:20
Visited 12 times by MSN, last 2014/01/18 02:15

< Generated in 0.48 seconds the 07/24/2014, 07:23 PM by Izumi 1.1.4 >