Comparing versions
Version 4Current version
bitweaver was a originally derived (forked) from the PHP Wiki application called TikiWiki. However, after 8000 code changes, the differences between bitweaver and TikiWiki are numerous to say the least. Here are some important differences:

What are the key differences between TikiWiki and bitweaver?

;Modularity - We have completely encapsulated all the TikiWiki features into a there own self-contained feature, what we call a bitweaverPackage
;Speed - we are highly focused on speed and high performance.
;Features - TikiWiki is more focused on bells and whistles. This means bitweaver has chosen to deprecate many of the obscure features of TikiWiki. Because we have completely modularized the TikiWiki feature set, it is possible to bring any of the TikiWiki features into bitweaver at any time. If you are interested, GetInvolved with bitweaver!

What is the relationship between TikiWiki and bitweaver?


bitweaver started out as an experiment to modularise TikiWiki and allow admins to remove features they didn't need - not just disabling features but actual removal of the code. This makes the codebase customisable, performance tuned, and ideal as a Tiki Web Application Framework.

TikiWiki is a Content Management System (CMS) and portal application. bitweaver has taken all of the TikiWiki features and broken each into indvidual features. This new modularity allows bitweaver to be an ideal Web Application Framework which is extremely customizable and ideal for integrating all kinds of other applications - proprietary or open-source.

bitweaver supports many databases on Linux, Macintosh and Windows. bitweaver has added modularity, scalability (speed!), data integrity, and stability to the original TikiWiki engine, This makes bitweaver much more suitable for enterprise or large scale, high traffic websites. Its ease of use makes it ideal for small sites as well. bitweaver will still have all the great features that made TikiWiki famous, but has made the integration of applications much easier.

Is it compatible?

Yes, you can upgrade.

bitweaver ReleaseZero, uses the identical schema as TikiWiki 1.8, and should be schema interoperable with a TikiWiki 1.8 install. ReleaseZero has all features of TikiWiki 1.8 working, and was an interim step between TikiWiki's all-in-one approach and bitweaver's modular framework.

bitweaver ReleaseOne introduced massive improvements in many aspects of the original schema, and ground breaking advancements in the CMS engine. This resulted in many schema changes, however we have created upgrade scripts that will eventually update the schema's of previous bitweaver and even TikiWiki releases. The upgrade

The larger question is what about neglected features of TikiWiki that are little used? Support for features is dependent on the interest of the community. Being an application framework, bitweaver considers each feature as a small application inside of it - what we call "Packages". Not all code is good code, and we don't want poorly written or neglected code to slow down the advancement of the most important features. What this means is that from ReleaseOne forward, not all TikiWiki features may get updated for future releases.

So are you guys a fork?

Yes we are. We had hoped to work within the Tiki community, however, TikiWiki's inactive founder made this unfortunate decision very clear that when he stated he would "strongly stand against making this changes a part of the Tiki distribution for the public." More info...
 
Bitweaver was a originally derived (forked) from an application called TikiWiki. However, after tens of thousands of code changes, the differences between bitweaver and TikiWiki are numerous to say the least.

Key differences

Modularity
We have completely encapsulated all the TikiWiki features into their own self-contained feature, what we call a bitweaverPackage.
Speed
we are focused on high speed and high performance.
Packages
TikiWiki seems more focused on addon-like features. Bitweaver has chosen to deprecate many of the more obscure features of TikiWiki. However, because bitweaver has completely modularized the TikiWiki feature set into packages, it is possible to bring any of the TikiWiki features into bitweaver. If you are interested, get involved!

Relationship

TikiWiki is a Content Management System (CMS) and portal application. Bitweaver started out as an experiment to modularise TikiWiki and allow admins to remove features they didn't need - not just disabling features but actual removal of the code. Bitweaver has broken TikiWiki's features into individual packages. This new modularity allows bitweaver to be an ideal Web Application Framework which is extremely customizable and ideal for integrating all kinds of other applications - proprietary or open-source.

Bitweaver supports many databases on Linux, Macintosh and Windows. Bitweaver has added modularity, scalability (speed!), data integrity, and stability to the original TikiWiki engine. This makes bitweaver much more suitable for enterprise or large scale, high traffic websites. Its ease of use makes it ideal for small sites as well. Bitweaver will still have all the great features that made TikiWiki famous, but has made the integration of applications much easier.

Compatibility

bitweaver ReleaseZero

Bitweaver ReleaseZero uses the identical schema as TikiWiki 1.8, and should be schema interoperable with a TikiWiki 1.8 install. ReleaseZero has all features of TikiWiki 1.8 working, and was an interim step between TikiWiki's all-in-one approach and bitweaver's modular framework. See bitweaverUpgrade and bitweaverFAQ

bitweaver 1

Bitweaver ReleaseOne introduced massive improvements in many aspects of the original schema, and ground breaking advancements in the CMS engine. This resulted in many schema changes, however we have created upgrade scripts that will eventually update the schema's of previous bitweaver and even TikiWiki releases. See bitweaverUpgrade and bitweaverFAQ

bitweaver 2

See bitweaverUpgrade and bitweaverFAQ

Neglected features

From ReleaseOne forward, not all TikiWiki features may get updated for future releases. Support for features is dependent on the interest of the community. Being an application framework, bitweaver considers each feature as a small application inside of it - what we call Packages. Not all code is good code, and we don't want poorly written or neglected code to slow down the advancement of the most important features.

In the beginning


As is tradition in the open-source world, bitweaver was forked from a predecessor. Begun in 2003, a few developers began to try to extend the TikiWiki portal application to support enterprise class websites (millions & millions of rows) by integrating custom functionality and existing open-source projects. While this was possible to do, it upset the goals of the TikiWiki project as an all-in-one portal application for smaller, simpler sites. And thus fork began.

TikiWiki was chosen as a starting point because of its many brilliant software designs, is loaded with features, and is very neatly organized. Unfortunately, TikiWiki has all of its features glued together. To begin a metaphor, TikiWiki is like a deck of cards. The numeric value represents a feature (blog, wiki, photo gallery), the suit represents a functional piece (template, library, logic). Now imagine the deck sorted by suit, and glued together. It makes a powerful feature set, but unfortunately it is a all or nothing proposition.

bitweaver developers decided that they did not want to even know about code they which they had no interest. In fact, they did not even want it on the server. The encapsulation normally reserved to software design was extended out to the feature set itself. So began a basic rule that any feature should be able to completely removed from the server, and no trace of that feature should be present in any of the remaining source code. This rule is what led to the development of "Services", as you will see below.

Following this rule, the developers unglued the TikiWiki source code deck, and arranged all the cards by suit. This left 13 piles, and thus each feature set nicely in one folder. This created a core notion of bitweaver, the "package", which at its simplest form is just a directory in the application root direction with a little or a lot of code. The word package was chosen as opposed "plugin" because bitweaver uses large grained modularity. Enormous amounts of code can exist in a package. In fact several packages contain their own plugin architecture.

A few of the piles, or packages, were crucial to the running of the system, the face cards following our metaphor, and those were dubbed the "bitweavercore". These are the packages that are required to install bitweaver, and login. There is not functionality beyond users and the main content engine. This is a great place to start writing your own application. You can checkout the bitweavercore with "cvs -d:pserver:anonymous@bitweaver.cvs.sf.net:/cvsroot/bitweaver co bitweavercore" and you are ready to go!

Once the bitweavercore was settled, bitweaver began to actually simplify and remove features. A central content engined was added, called Liberty, which moved object oriented princples into the database tables directly. It evolved from a portal, to CMS, and finally today as a true framework with an extensive built in feature set.
Page History
Date/CommentUserIPVersion
26 Oct 2008 (09:33 UTC)
consolidated with included 'archicle' for easier maintanance
laetzer85.179.34.17412
Current • Source
laetzer85.178.62.11711
View • Compare • Difference • Source
laetzer85.178.62.11710
View • Compare • Difference • Source
laetzer85.178.62.1179
View • Compare • Difference • Source
Marc Archuleta67.149.245.2146
View • Compare • Difference • Source
xing194.152.164.455
View • Compare • Difference • Source
spiderr66.93.240.2044
View • Compare • Difference • Source
spiderr66.93.240.2043
View • Compare • Difference • Source
Stephan Borg218.214.1.1132
View • Compare • Difference • Source