( ! ) Warning: session_start(): open(/var/lib/php/session/sess_isohu1al89mgd71lh1de07cp90, O_RDWR) failed: No such file or directory (2) in /var/www/bitweaver/live/users/includes/bit_setup_inc.php on line 82
Call Stack
#TimeMemoryFunctionLocation
10.0000231488{main}( ).../index.php:0
20.0001233544require_once( '/var/www/bitweaver/live/kernel/includes/setup_inc.php' ).../index.php:16
30.01801907288BitSystem->scanPackages( ).../setup_inc.php:141
40.01972175568BitSystem->loadPackage( ).../BitSystem.php:1183
50.01972178600include_once( '/var/www/bitweaver/live/users/includes/bit_setup_inc.php' ).../BitSystem.php:1109
60.02002582848session_start ( ).../bit_setup_inc.php:82

( ! ) Warning: session_write_close(): open(/var/lib/php/session/sess_isohu1al89mgd71lh1de07cp90, O_RDWR) failed: No such file or directory (2) in /var/www/bitweaver/live/kernel/includes/classes/BitSystem.php on line 580
Call Stack
#TimeMemoryFunctionLocation
10.0000231488{main}( ).../index.php:0
20.03123434344include( '/var/www/bitweaver/live/liberty/includes/structure_display_inc.php' ).../index.php:22
30.03863631064include( '/var/www/bitweaver/live/wiki/includes/display_bitpage_inc.php' ).../structure_display_inc.php:19
40.04603683728BitSystem->display( ).../display_bitpage_inc.php:163
50.04673685568BitSystem->preDisplay( ).../BitSystem.php:505
60.04803700048session_write_close ( ).../BitSystem.php:580

( ! ) Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in /var/www/bitweaver/live/kernel/includes/classes/BitSystem.php on line 580
Call Stack
#TimeMemoryFunctionLocation
10.0000231488{main}( ).../index.php:0
20.03123434344include( '/var/www/bitweaver/live/liberty/includes/structure_display_inc.php' ).../index.php:22
30.03863631064include( '/var/www/bitweaver/live/wiki/includes/display_bitpage_inc.php' ).../structure_display_inc.php:19
40.04603683728BitSystem->display( ).../display_bitpage_inc.php:163
50.04673685568BitSystem->preDisplay( ).../BitSystem.php:505
60.04803700048session_write_close ( ).../BitSystem.php:580
bitweaverDesignGoals - bitweaver

bitweaverDesignGoals

Created by: mikelcu, Last modification: 01 May 2004 (04:37 UTC) by SEWilco
bitweaver Design Goals
This page is in the proposal stage, so things are still very much open to comment. Please drop by IRC or post to bitweaver-development@lists.sourceforge.com.

Disclaimer: I make some generalizations about application types, specific applications and other things here. Don't take every word as law, there is no way I can cover the fine-grained details of this entire subject in one document.
This page will be the discussion for us all to put in our 0.02 to say exactly::

  1. What do you think Tiki is now? Pros? Cons? Why?
  2. What do you want Tiki to be?
  3. What native features we would like to see in the answer to #2. Why (if you feel like it)

These questions are not as easily answered as one might think. First let us define a few things.

Native features - This means NO addons. using my favorite nemesis, Plone, I will provide an example. Plone is a wholly integrated CMS/DMS with it, you can create, edit and manage douments and media of various types. It natively supports (X)HTML and DTML for added content, and can accept and identify almost all uploaded document types (though it cannot display them without addons). That and more make up Plone's main features:
  • Content Management - write/edit/store documents
  • Workflow
  • Full-text Search
  • Portable user storage and authentication (this comes from zope)
  • Document discussions
  • Template-based content presentation (somewhat xhtml compliant)
  • Filesystem-style hierarchical content layout (modifiable)
  • Full revision control of every document or file added
  • Treats uploaded files the same as created documents (therein is the combination of CMS/DMS, it treats content as documents)

CMS - I know we all think we know what this means, but lets define it explicitly. A Content Management System is some kind of application that allows the content of a website to be managed, edited and changed easily; most often geared for use by non-technical staff. A pure CMS does not necessarily have forums, discussions, or any other addon features (see http://www.callistocms.com for example) Callisto is an absolutely pure CMS, you create a site and manage all it's content with the app, it does not do forums, polls, etc.. Public corporate sites are the most likely canitdates for using a CMS.

DMS - Document Management System - In essense, a glorified web file manager. In practice, a DMS can accept existing documents of a variety of formats, and standardize their presentation and/or their accessibility. A pure DMS may not really do anything to the documents it stores, it may only organize, index and display them. Corporate intranets often use a combo of a CMS/DMS (not including applications like webmail or other groupware).

Engine - I'm just using the word "engine", you could call it whatever. A site engine is usually some kind of combination of CMS possibly a DMS and usually quite a few addon featurres. Perfect examples of this are PHPNuke, PostNuke, Drupal, and of course TikiWIki. Plone also considers itself an engine, but I don't listen to them. Engine-style sites are often driven on a newsbyte style content format that is updated frequently, instead of the long, less fluid document style used by a DMS or CMS.

Enterprise - This does not mean "busy" or just "big". When I plan an enterprise scale framework for something, I look for Scalability, Redundancy, Failure Resiliency (this is not the same thing as being redundant), Performance and Security. An Enterprise will expect 99.99% uptime or better and stable upgrade paths. No PHP-based CMS I have ever seen covers all of these.

Why do I not call *nuke or Tiki CMS's? Because although a site engine application offers numerous ways to control the content of the site it runs on, it is NOT geared towards raw content management. The strength of a site engine generally lies in the bundled or add-on applications (modules, mods, block, it's all semantics) that it can use. Stripped of all addons, most site engines don't do very much, and at that point may not even be able to control content very well.

Why aren't I calling forums and such "content"? Forums and other such features are generally extensions or addons. The core of a web app may or may not support a feature like this, but the base content implies the "core" of a site, i.e. if I have a site about monkeys my 10 pages about monkeys are my content, whereas the forum for discussion of monkeys is an addon application or extension of the core functionality.

CMSs DMSs and Engines are NOT mutually exclusive! We can all see this with every app like Tiki. Some engines really are CMSs, some DMSs are CMSs, come CMSs have engine features. You don't have to pick just one, you just need to be specific in the features you want to see in the core.


mikelcu aka Mike Culbertson aka troublemaker

I think ((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 is an Engine, with some really powerful CMS-like features and apps. I think it was developed organically without a solid plan, or at least not one that was followed.

Pros: The wiki, the userbase, adodb, smarty, lots of clever and fast code
Cons: Poor security design, cluttered presentation, often obtuse menus options (create a new Wiki page how??), a inherent lack of flexibility coded into the core...there are hardcoded paths, filenames, etc. all over the place. The file organization and naming standard are sophmoric.

I would like to see the /idea/ of Tiki become what products that Plone, Interwoven and similar are NOT. A real CMS that can be used in an enterprise /with/ the features that make it attractive for use on smaller sites. There is a medium between corporate stoicism and opensource hacker fun and I think that something derived from tiki has the potential to be that.

Mike & Brian's Core Feature List
My core feature list comes from a conglomeration of features found in other CMSs.
  • Flexible storage backend - Support for multiple DBs should be native from the beginning. SQL queries should be 100% portable /or/ there should be different subsets of queries depending on backend...the app should NOT be married to any one data source.
  • Mobile User Base - This /must/ be able to retrieve and store user information from any source. An abstraction layer could provide auth from LDAP, SQL, Radius, Kerberos, anything. A flexible API would allow new auth modules to be added by 3rd parties.
  • Layout - An organized application layout is essential. There are innumerable organizational and security implications to the way an application is laid out on the filesystem (I know, I do it for a living).
  • CMS core with modularity - My ideal app would be a CMS at heart, with all authentication and data storage handled by the core. Additional functionality such as forums/polls/etc would all be extensions or modules. In it's raw-est form, the app could manage a nice 10-page site with nearly static pages. Also, the core would be written with assimilation in mind. I do NOT want to write another forum, phpBB already did it and theirs is better. THe same thing applies to many apps. PNphpBB is a great idea and the core should be planned with things like that in mind.
  • Dynamic Content - Wiki-style collaboration and/or commenting.
  • Full-Text Searching - Anything edited/added/uploaded into the app should be at the minimum indexed for a /smart/ search feature. The core must store information with the idea of finding it later well in mind
  • Full Revision Control - Any and all documents/files/objects managed or stored by the app would have revision control applied to them (configurable)
  • Standard Output - The output format of the application would be XML or XHTML using CSS. Every page without user input screwing it up should validate 100% at w3c.org. Why? /real/ compatibility. There will always be browser bugs, but being 100% standard is the easiest way to keep the field even. (If you think XML or XHTML is not backwards compatible, visit www.callistocms.com with NN4)
  • Modular Output - The theming and templating framework must be designed with the idea that sites will NOT follow the standard header/3 colums/footer layout. Making each displayed component truly a modular piece lets users redesign their own site in any way they see fit. (no open-source CMS/Engine I know of supports this without quite a bit of hacking)
  • out-of-the-box usability - The default app would have enough usable/compatible templates and GUI-configurable options to let anyone install it and set up a site.
  • Enterprise Attitude - The world does not need another nuke. The app would be planned with the intention of use in an enterprise, with support for individuals. As fun as they are, quiz addons are not a bonus when picking a corporate intranet. However, any and all contributions should be strongly encouraged. Brilliance comes from the most unusual places, plus you never know who will want what :)
  • Fully Documented API - extensions and modules must have a properly documented API to use for easy development (think smarty)



jomar aka John Riley

It seems to me that ((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 is conglomeration of various open source capabilites that outgrew any roadmap that it may have had at one time.

Pros:
  • A lot of capabilities at an excellent price.
  • An exciting approach to loosely managed communication.
Cons:
  • Documentation is poor and / or lacking and / or outdated (installation, administration, usage)
  • User interface is at times eclectic, non-intuitive and cluttered.
  • Quality / reliability from release to release is highly variable and unpredictable.
  • Impact to users of changes / enhancements are not fully documented
  • Architecture not modular enough. More modules and fewer core features. Mods must be easy to install / develop.
  • APIs and developer processes not well documented

I guess my perspective is that it's a communication tool. It seems, from the 40,000 foot view that it's a tool that allows people to present, solicit and collaborate. I see no need to limit it's ultimate scope, as long as it's possible to manage it's diversity / complexity.

My Core Features List
I'd like to see bitweaver have an infrastructure "core" and lots and lots of optional user-contibuted modules:
  • Modular Presentation, Database, File, Intra-module communications, Administration and Initialization subsystems with associated APIs
  • Wiki, Forums, Articles, Blogs, File Galleries and FAQ's as the "baseline" module set (give or take a few)
  • Being a software developer, I'd like to see software development lifecycle support modules
  • Need to be able to install and configure quickly (including the ablitiy to encapsulate stored setups for easy site replication)
  • Needs to be very readily "themed" (branded)
  • Need the ability to readily and quickly add capabilities
  • I'm thinking that, due to site entropy, there should be ways to easily reoorganize, sift and categorize content periodically.
  • I'd dearly love to see automated testing / validation capabilities. I think that would go a long way toward managing quality and minimizing wasting precious developers' time. It would also go a long way toward developing customer confidence

Thoughts from an application developer
Remember: Wiki, wiki, wiki.

Why? Principles:

1. As we have learned to our dismay, most of our users are never going to learn HTML.
2. The "Webmaster" syndrome is killing us. Every little change has to go through the Webmaster.
3. We (application developers) are DESPERATE for a package that enables us to DISTRIBUTE page maintenance responsibilities to end users! But no HTML!

This is why we are trying to use Tiki.

Tiki isn't EVER going to be used for an enterprise's public Web site, where the Webmaster is still very much in charge (and has to be). It is already used in who-knows-how-many intranets, non-profits, NGOs, semi-public collaborative sites, etc. Because of the Wiki!

So:

Market identification: engine + wikified CMS

Implications for Design:

1. Make sure that the core of bitweaver is the Wiki — and what is more, that the Wiki is state of the art. Carefully study TWiki.
2. Build automated site generation tools into the Wiki core, including automatic menu generation and option to include a new Wiki page in a specified menu! (See typo3 for an excellent implementation of this concept)
3. Keep the Wiki syntax simple! Tikiwiki's syntax has gotten out of hand, particularly with plugins.
4. Add capability to give individual-level permissions to pages (the current page creator is owner is a start, but doesn't go far enough).
5. Build INCLUDE capability into the Wiki so that text never needs to be repeated.

--bryan