There are several approachs to look in that direction. One can say, i.e. "If one start to remove features, what should be left for still calling the remaining Tiki?". Or take some sort of evolutive approach, with what minimum set of features I could build most of existing functionality without too much trouble? Or define what is common to most existing features, and put that as the core. Another way to see it is a myopic way of see actual tiki, where details are blurry and what "looks" similar (in presentation, how to use or conceptually) could be put as things in core, and details that differentiate them as external modules (think in what is so different between a generic comment system and a forum, or a blog with graphicless articles, or the bunch of "selecting choice" alternatives that are available)

For this, I like the idea of a minimum set of features that enables to build most things, and maybe do that in a general enough way to enable not only the creation of current Tiki features, but also more derivatives or a more orthogonal system, reusing things whenever is possible.


For me still is one of the main Tiki features, to be able to write content for the web with a very simple but powerful enough syntax is a very strong point. But for putting it in something "core" and be reusable, could be nice to have a simplified, generic version, one that accepts "plugins", not in the sense of the actual plugins, but additional pluggable syntax parsers for derivatives, for i.e. to have a full wiki with a parser that put MixedWords as links, or embedded objects, or links to other system features. This simplification could mean that maybe we can use wiki text in most places on the system that in some way or another a textarea is used.


A core user base, with maybe extensible attributes, or relationship with another objects (pages, groups, files, etc) should be there.

Another Tiki caracteristic, a menu system. Generic enough to enable to link all existing wiki features, or creating any number of system and user menus to be used anywhere.


This could be used for manage from image/file galleries, attachs, selected downloads, etc. If generic enough, could be implemented in such ways that the rest of the system should not worry if the files are in a database, in the filesystem or in the network. A mime system could give a proper way to manage, display, edit, show icons/thumbnails etc around the system.


There are several kind of "collections" in actual Tiki, some with special capabilities and attributes, that can be clasified as follow

Thread Collection

Normally for texts, but could be used for more things. For a given object, you can have for "directions", next/previous element, up (father) and down many number of childrens). For forums, comments and such is the first way to use this, but, if implemented generic enough, could be used to put files, images, and other kind of system objects here (even an organization scheme composed with users)

Ordered Collection

This could be used for implementing actual image galleries or file galleries, where maybe is important the order

Unordered Collection

For some things order is not important. Maybe some kind of file galleries could be managed that way, but also actual categories could fall in this kind of collections. Also could be used to cover group of users, in example.

Date Collection

If a kind of ordered collection, but with a special meaning, dates. Around this most calendars could be built, or things that depends on dates.

Permission system

In the most generic way, it could be used to describe relationship between objects and features, i.e. object A can do "feature" (being feature a very dinamic set), but object could be an user, a group or even more weird things (if wiki is used around all the system, could be interesting to be able to disable some special wiki feature, i.e. illustration or including images, for forums but not for other sections)


See them as a very basic trackers, and that could be used in very generic ways, i.e. a future module that takes a table and uses it as a chart or a survey, or the contact form or a generic input/report form generator).


This is just one point of view, with certain deepness in how far we can go to core. But we can have a a lower or higher level of abstraction. Instead of plain collections go directly to file galleries, or a comment system (i.e. for commenting objects in general or implement forums) or just a generic calendar instead of a date collection.

Maybe putting categories or groups of users as collections is going too deep also. A nice thing where to put some orthogonality is the "belong to" concept. An object or feature could belong to the system, but if things are implemented in a generic enough way, why not put objects, permissions etc, that also could belong to users or categories? I.e. you have the "main" Tiki, but you could have a subtiki related to a category or an user, and have forums, blogs, a collection of wiki pages, galleries and trackers that belongs to an user and not have meaning or are not listed with the upper level components. For a category I could want to have special features enabled (i.e. illustrations for only the wiki pages that belongs to the manual), the same for a group of users or a special user (wiki features are too fixed in the idea of for all or for nobody)

Page last modified on Wednesday 13 August 2003 06:25:13 GMT-0000