Created by: btodoroff, Last modification: 13 Nov 2008 (18:21 UTC) by xing

Here is Spider's bitweaver vision:

bitweaver is all about freedom. It is the freedom to integrate your own features into a bitweaver install and not have to touch any other code. Maintaining a virgin install while and being able to add your own code is at the heart of the design.

So what is the design?

The design is a simple directory for each feature in the root.

"What, that's it?!" you might ask? Yes, at the barest of barebones, all you need is a directory. A bitweaverPackage is simply a directory in the root. At that point, what you put in the directory is entirely up to you. You can put WHATEVER you want in there - perl, CGI, HotScripts.... anything. If you would like to have your bitweaverPackage integrate with the larger Tiki system, there are API's and mechanism's you can implement. For example, it is possible to extend a Wiki Page and add your own functionality. Or maybe you want to add a commerce system custom tailored for your site, however, let Tiki manage all the other stuff. However, the extent to which you want to integrate with Tiki is really up to you, and that let's you make the best solution possible for your problem.

... more to come ...

Everything below here is old.

Life started as a module for ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and bitweaver and TikiWiki called spidercore. This was a first pass at experimenting on what was easily possible.

My first objective was simple: I wanted like to make Tiki much more open to other people's code.

I wanted to put phpBB, Gallery, SquirrelMail,or any of the multitude of other open source web applications into Tiki. Tiki is a great piece of software, one which I settled on after reviewing all open source CMS systems. The ADODBSupport was a major undertaking, and one that enabled Tiki to move into much more demanding environments.

However, the initial ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and bitweaver and TikiWiki code base had become very inflexible and cumbersome to work with. All things considered, it was in very good shape, and just needed a little moving around to open up a whole new world of potential development.

My second objective is simpler: I want to modify as little existing Tiki code as possible.

There is a lot of great code in Tiki and I have no interest in rewriting any of it. However, it needs to be better organized so external code can coexist peacefully within Tiki code, and coexist with other alien code trees within Tiki.

Phase 1 - Tiki Packages ( aka Directory Restructuring )

My design is simple: Put all files related to each feature into their own directory

First attempt complete!

You can peruse http://cvs.sourceforge.net/viewcvs.py/tikiwiki/spidercore/ to see initial attempts at the reorganization, or an in progress demo. Most everything has been put in a much more logical, modular grouping. Nothing was thrown away, nothing was added. I did not want to write any functionality because I knew the code that's there will work once I fixed paths and includes.

Change as little code as possible (and absolutely NO database tables) - simply reorganize the codebase into properly encapsulated directories. Advancing UserPagedheltzel's concepts and name, each directory is known a bitweaverPackage.

The Golden Rule of Tiki Packages: Tiki should place the fewest possible requirements possible for a bitweaverPackage

A Tiki Package is simply a directory in the Tiki root directory. The only requirement is a single file called "setup_inc.php" that will get included by TikiSetup. Optional files will include a "local_inc{{.$tikidomain}.php" for settings particular to a user's install. A bitweaverPackage will be all of the integrated features in lib/* or it could be an external app, like phpBB, adopted to use the Tiki framework.

The solution is low tech and dirt simple. I do not see insisting on a large API infrastructure when some Packages might only need to execute a few lines of code. Other Packages might need a complex architecture. So let developer's decide for themselves how simple or complex to make their own Package. This should also allow ports to stay as virgin as possible, and stay much more up to date with their own code base.

Tiki's current "lib" directory works very well and is the model for where I would like to start. My answer is to simply stuff all code for given features (wiki, blog, article, forum) into the existing lib directories. I would like to move the lib/* directories up out of the lib directory so that the Tiki root is one or two php files and bunch of directories, such as:

|- db/
|- core/
|- blog/
|- wiki/
|- phpBB/
|- gallery/
|- newFeature/
|---> setup_inc.php
|---> local_inc.php
|---> local_inc.www.multisite.com.php
|---> /templates
|---> /modules
|---> /admin

There is a common KernelPackage that is simply a chopping and moving of the existing tikilib & tiki-setup files.