Planning - Concepts.

The initial idea from which this project will grow is that forum software should not be a ready made package that comes with a particular look and feel. Instead, it should be based on backend code, we do the hard work of writing the objects and methods, and provide them as class files in PHP, for inclusion in your own website. From here, the site owner looks up a tutorial and other examples as to how to call the code to make it do what he wants, using a well documented API (Application Programming Interface).

By it's nature, no 'visitor facing' pages should be necessary, they should be built by the site owner as he or she feels fit. This of course infers that if the site owner must create the visitor facing pages, he should have complete control over the look and feel of the pages themselves. And this is 100% true. The forum project should not contain any display code except through the use of templates that the site owner can customise.

We are able therefore to produce the following as a rough overview:

1. The site owner downloads a package from us containing the PHP scripts that form the forum code, and the documentation.
2. He reads a document, "How To Install", and finds that he should put files x, z, and y into a directory where his code can include them.
3. He is told to consult the tutorial to see how to include the forum software in his own project, and how to use the API to display example content. We should include a small but complete database dump file to permit the owner to see for himself how it works.
4. By modifying the tutorial, or by starting from scratch, the owner should be able to code his own site to call the forum software via it's API to display forum content.

At no point should we interfere with his mechanisms for storing data other than that critical for a forum to operate. We don't need to know how he stores his user or client data. We don't need to know how he tracks his visitors (if at all). We do need a particular way of storing our forum data in a database.

The software itself should be componentized into classes that can be instantiated as objects in memory. The objects should maintain data structures and methods. The data structures may hold objects themselves, such as a forum object holding many message objects.

Methods to obtain meta information about the forum, and to send meta information to the forum should be public. We may, for instance, call an object to display a message; the message may in turn be asked to say which user id posted it. The calling software may then look the user up according to the site's own architecture and pass back user information to the object displaying the messsage. Using a message template, the message itself together with information about the user may be displayed.

Separation of this sort is I believe a crtical part of the forum's goals. Yes, this may infer a 'performance hit', but in the long term, it may suit the site a great deal better than potentially installing other more buggy or restrictive software.

We should at this point raise the inevitable problem of how the user should create the initial forum in his database. Well we can start by providing a database definition file, such as the output from the MySQL command mysqladmin -u <user> -p <password> databasename > database.mysql. From here we can expand and customise, which of course infers an administrative interface. From experience, this interface can be as daunting or even more so than the visitor's front end simply because administration tasks are often a great deal more involved than what a vistor sees and does. A separate API perhaps for this job, and possibly even a complete web front end should be provided.

It is highly likely that if we do not provide sufficient 'starters' for the site owner to begin from, s/he will simply browse to the next forum software site. It's 'plug-in-ability' is therefore of particular concern, as is strong and accurate documentation.

None of this, of course, will be of any use unless the code is usable and held in high regard by other coders in the PHP and web development community. No-one gets code of this magnitude right first time, so our 'Version 1' software is likely to contain architectural flaws that may affect it's uptake. 'Version 2' should iron out the issues troubling the initial releases. At each stage we must review the work to ensure it's goals are met and that no undue pain will be suffered by unneccessary changes to database schema or API, or lack of up to date documentation.

Indeed the release of each package must be well prepared to ensure accurateness and completeness.

These are high goals, but necessary to attain a high quality package of software that can be said to be the de facto available.