Written on
October 4, 2008
by
Mike Gerwitz
So, I’ve decided to split off the MCBB core into its own project, which will be developed alongside MyCustomBB. The core, which is now named WebCORE (or Web C.O.R.E. - acronym pending), will be distributed for everyone to use as a strong foundation to their own website. MyCustomBB, therefore, will be a a module pack, or collection of modules, extending WebCORE and providing the features you’d expect (and some you wouldn’t) from a bulletin board system.
This will also help make the long process more bearable. I’ll have something to show much more quickly. Once WebCORE nears completion, I will make its release, feeling as though I have one project complete, then continue to develop and tweak it as I continue to work on MyCustomBB.
I have submitted the project to SourceForge, where it will be hosted, but must wait a few weeks for it to appear. There already exists a project with the UNIX name of “webcore”, which has not been active in 4 years (since its creation). This project will replace it.
For more information, click on the “Core” link at the top of this page.
Posted in Development, Planning 
No Comments »
Written on
October 3, 2008
by
Mike Gerwitz
A couple months ago, I decided to begin complete reconstruction of the project - from scratch. The code was too old, slow, outdated, and did not follow the new standards I have set for the project. Certain parts have been salvaged, while others will be entirely redone. I’m very happy with the changes thus far. Here’s an outline of the current progress:
- Daemon development has begun. The daemon will be entirely optional and will help to speed up the system by handling many intensive and repetitive operations.
- Redesigned error system. The error system is now incredibly sophisticated. It now allows for error handlers to be registered with any error, so any script/module may handle an exception. Modules may also resolve errors and tell the system whether or not to continue or halt.
- Redesigned event system.
- Redesigned logger.
- Many speed optimizations.
- Heavy code commenting and phpDocumentor documentation.
You may take a look at the project on SourceForge’s SVN. There are some new project standards - one of them being that the trunk will always be usable (though not necessarily stable). Therefore, you may check out and test the progress at any time.
Some long-term project plans have changed. Certain things will be done differently this time around:
- Something to show for the work. Once the general core is complete, I’ll start working on usable portions of the project. Last time, I went straight for the Administration Panel. That is unncessary. Manual configuration and smaller scripts will suffice for the time being. Administration will be added as needed, after the part of the project to administrate is complete. This way, you can see what MCBB can do earlier on in the project.
- Heavy research. I have put countless hours into researching and planning out various aspects of the project, both for performance optimizations and how to actually pull something off cleanly and effectively. Before, I simply dove straight into it, using my experience with phpBB and other systems as a slight guide. Everything is now my design. Ideas may be taken from other systems, but I now think everything through.
- Get the core done quickly so others may help on the project. I work on MCBB in my spare time, so I can’t say how quick “quickly” will actually be. However, I wish to get the core into a stable and functional state so that others may begin helping out by fixing bugs, contributing ideas and modules. I want to build up a community and support for the project. Not only will this speed up the development (and take some of the load off of me), but it will also help spread the project and modivate me to work a little harder. I may also be looking for help in developing the core modules (such as the actual forums, member profiles, etc) - so look out for that later. But that’s after I establish a system, type out the coding standards, provide the necessary matierials and references, etc.
- Document my work. As I go, I now document major points in the wiki. This ensures that (1) I will hae an easy reference to my work and (2) that others may hop onto the project and understand what’s going on without having to study the code and make sense of it.
Furthermore, I’ve decided to take the core to another level. Due to its design, the forums, member profiles, etc would be best suited as modules - without any loss to performance. The core is a modular system. Every feature, except those built-in, are separate. Therefore, the core can be used for anything - not just bulletin board system. The core will include everything you need for any type of website. I also plan on using the core for my various types of websites. What does this mean? Sometime in the future, you can expect the following. They will be developed for personal reasons, but will be feature rich and ultimately released for others to use:
- Converters between phpBB and other bulletin board systems to MCBB
- Interfaces between MCBB and other systems (i.e., using phpBB’s database rather than converting it). This will allow me to test MCBB on my current websites before I switch it over.
- Ability to integrate Wordpress, among others.
I’ll have more information later.
Posted in Development No Comments »
Written on
July 22, 2008
by
Mike Gerwitz
MyCustomBB was designed with the intention of integration into other systems. Forums are only one part of a website - therefore, it can only be assumed that the software will be integrated into other systems. It needs to be ensured that MyCustomBB does not conflict with such systems. This means that variables, functions, classes and constants must be named in such a way that they do not conflict.
Therefore, the following has been decided:
- All constants will be prefixed with “MCBB_”
- All core variables and functions will be prefixed with “mcbb_” (e.g. $mcbb_user rather than $user)
- All core classes will be prefixed with “mcbb” (e.g. mcbbTplSys)
This will, obviously, require a bit of code re-writing. However, considering I’m going through every file as it is to bring it up to new standards (some code is nearly two years old), I would rather do this now than later. It will also be tedious for developers to use the prefixes, but I feel it will pay off by allowing administrators to easily integrate MyCustomBB into their site.
I have also decided on a PHP version to push toward - PHP 5.1.x (hopefully 5.1.2). The minor version may change, however I will be sure to make any features that require higher PHP versions optional. I did not want to require 5.2.x because I am unsure how many web hosts use that version (hell, I’m unsure how many use 5.1.x). 5.3.x is tempting, but I’m afraid I must resist. No web hosts would support it for quite a while 
Posted in Development No Comments »
Written on
June 27, 2008
by
Mike Gerwitz
I’ve decided to put the Datapack system on hold for the time being, even though it’s nearly complete. Because I’ve redesigned the database backend even further, it serves no immediate purpose. Right now it’s simply slowing the project down. Therefore, I’m getting back to work on the reconstruction.
I have been trying to think of the best way to implement a database backend. The problem is - how do we support multiple database server efficiently? Other systems simply convert the queries at runtime. For example, when a query is generated, it is generated in one format (such as MySQL). That query is then passed to the database layer where it is handles appropriately. If MySQL is the selected server, great - nothing needs to be done. The query is sent to the server as it is and we move on with our lives. However, if the administrator has chosen a different format - say, PostgreSQL or a flat-file database, the query may need to be altered or converted so that the server can understand it. So, it is converted at runtime before being sent to the server. This is an unnecessary waste of time and will slow down execution for other database servers.
So I figured, the query should be generated in the proper format to begin with. That way, no conversion is necessary. This will require more work from the developer’s perspective, but will be worth it performance-wise. So I thought about implementing the query functions in the database class itself. But this raised some problems - how would user-created modules add to that? PHP doesn’t support the dynamic addition of class methods without the use of an extension. And having MyCustomBB rely on an extension is a very bad idea.
So, the approach I decided on is $db->extension_name->query_function(). This introduces database extensions. Database modules handle communication with the server. Extensions add functionality to the module. So when a user-created module is loaded (non-db module), they can call a function that will enable and add the extension. If the extension does not support the server that the administrator has selected (which I’m sure many user-created modules will not), it will instead load a converter extension which will serve as a bridge between the database module and the user extension. It will then use the slower method of converting the query before sending it to the server. If no database modules support (know how) to convert between the two query types, the system will prevent the module from being loaded to prevent errors while users are browsing the site. (This, of course, means that the module that uses the extension will be prevented from loading.)
Posted in Planning No Comments »
Written on
June 5, 2008
by
Mike Gerwitz
After experimenting with a number of different project management systems, I decided to simply make use of the rest of the SourceForge features. All development-releated information will be located on the project website on sourceforge from this point on. It is located at the following URL;
http://sourceforge.net/projects/mycustombb/
MyCustomBB now has a channel on irc.freenode.net - #mycustombb. Feel free to stop in.
Posted in Development No Comments »
Written on
May 23, 2008
by
Mike Gerwitz
Well, since PHP6 is still under development, a few things took longer than expected. But, below is a link to the script in SVN for what I did research a bit. I’ll have more updates and PHP6 development continues and features are refined.
http://mycustombb.svn.sourceforge.net/viewvc/mycustombb/trunk/tools/test/unicode-php6.php?view=log
Posted in Development, Planning No Comments »
Written on
May 18, 2008
by
Mike Gerwitz
As I was working on the datapack wrapper, typing “strlen()”, I thought of PHP6’s unicode support. I decided that before I went further, I’d download it and test it out to see if the support was exactly what I thought it’d be and how I may need to modify my code in order to ensure that it was both compatiable with PHP6 and backward-compatiable with PHP5.
I’m creating a test script to highlight some changes (mainly unicode) between PHP<6 and PHP6. The code will run on both versions but will yield different results, allowing us to see what we have to deal with. I’ll place the script in SVN once it’s complete for others to look at in the hope that it’ll help clear up some confusion.
Posted in Planning No Comments »
Written on
May 16, 2008
by
Mike Gerwitz
The datapack system is (finally) almost complete. I had wanted it to be complete last week so I can get back to work on the backend (working on the same thing over and over is quite tedious and discouraging), however I found myself short on time. This has been a great lesson in planning - the datapack class has been rewritten a few times (large sections, not entirely). I’m almost done converting it to a stream wrapper and making some minor optimizations before I can make a BETA relese. It has been tested extensively, however a final release will not be made until it has been proven bug-free within the MyCustomBB project itself.
The class, developer documentation and example code (used to test every aspect of the system to ensure it is bug free) will be released as soon as it is complete. The class may not yet be found in SVN. It will be placed there once it has reached a stable state (directly before the first release). I hope others will find use for the wrapper outside of MCBB. Its only dependancy is the IOException class developed for the MCBB core.
Posted in Development No Comments »
Written on
April 21, 2008
by
Mike Gerwitz
Sun Microsystems recently announced they will begin making certain parts of MySQL proprietary:
http://developers.slashdot.org/article.pl?sid=08/04/16/2337224
As a strong supporter of free software, this will cause some changes in MyCustomBB. Initially, the database backend was going to be designed around MySQL. Now I will be designing it with both MySQL and PostgreSQL in mind, so that if Sun goes too much further, PostgreSQL (an entirely free alternative) can become the default database backend for MCBB. What does this mean? Simply: MCBB will be optimized for both servers. Database support created through modules, while I’ll try to design the system to run them as quickly as possible, will always be a little bit slower than what MyCustomBB was designed to work with. So instead of simply having PostgreSQL be one of those additional modules, it’ll be one of the core modules and will therefore run more quickly.
Either way, MySQL support will never be dropped. This is simply to ensure the free software community has something to fall back on in case MySQL goes further downhill.
Posted in Development No Comments »
Written on
April 21, 2008
by
Mike Gerwitz
I have been trying to determine for some time now whether or not to provide unicode support in MCBB for PHP versions less than 6 (which will support it natively). I’ve determined that, because MyCustomBB will, more likely than not, be released after PHP 6, it will not be worth investing the time to build in unicode support for lower PHP versions. Therefore, users of PHP 5 and lower will not have unicode support. However, when you upgrade to PHP 6, MyCustomBB will detect this, convert the character set of the necessary tables and you will have complete unicode support.
My reason for not adding unicode support to previous versions is because it will slow down the system too much - the system I am trying to optimize as much as possible. PHP 6 will natively support it and is compiled with highly optimized C code - much better than an interpreted language. Therefore, anything the PHP developers write will be faster than anything I could write in PHP. I also don’t want MCBB to have extra depricated unicode functions (that I would have created) when someone switches to PHP 6, providing redundant support and slowing it down even more.
Posted in Planning No Comments »
