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 »
Written on
March 29, 2008
by
Mike Gerwitz
I’ve been busy lately with personal matters so, for the past month and a half or so, MCBB hasn’t really moved. Work will be slowly continuing now with the reconstruction. At the moment, I’m still working on the datapack (which I’m modifying to be used as a stream wrapper). Once complete, reconstruction will continue.
Part of the reconstruction I have considered is using XML and XSLT in place of HTML. A few more details are provided on the project info page - don’t want to repeat myself here. I had considered it a while back, then dropped it. However, considered everything mentioned there, I believe it may be a good idea to go with it. Should that be the case, the template files will be converted.
Posted in Development No Comments »
Written on
January 12, 2008
by
Mike Gerwitz
Development of MyCustomBB has been a bit slow lately, but not without reason. I’ve been going over the code to modify and optimize a number of things. Speed has always been one of MyCustomBB’s goals, but I’ve been doing a fair deal of research into optimizing the code and feel that it will defiantly pay off, especially when it’s used for sites that get a great deal of visitors per day.
Such optimizations have also introduced a “datapack” class - essentially, it is a small file system within a file (a pack). There are two types - the standard one, which is optimized for reading and portability (consisting of a single file), and a keypack, which is optimized for writing (consisting of two separate files, one to store the data and the other to store the descriptors for that data). The datapack will be used for information that is primarily read from, as it is very slow to write to (such as language packs). The keypacks will be used for caching.
I’m also taking this time to go over the code and conform it to the new coding standards (which I will make available in the coming months). With all of these changes, I’m essentially re-writing much of the project, with the exception of the template system. The template system is nearly ready for its next BETA release, though that will come after all of the code optimizations.
There are also a couple other exciting developments that I will keep under wraps for now until I ensure they will work properly.
Posted in Development No Comments »
