UBB.threads PHP Forum Software Community Forums UBB.classic UBB.classic 6 Support New product - mySQL concerns??

Bob:

Could you be a little more specific with your concerns? What, exactly, about MySQL (proper capitalization <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" /> ) concerns you? Setup? Maintenance? Optimization? In all honestly, only optimization takes more than trivial effort, and even then there are a set of general rules and guidelines that can be followed. (If you can configure Apache by hand, you can configure MySQL without breaking a sweat.)

Also, could you elaborate on exactly what you've seen go wrong with UBB.threads imports? I'm a little too familiar with the issues involved, so I may not be putting enough emphasis on certain issues that mean little to me but are of major importance to others.

Other than the complete, total change in UI, that is. That I understand completely - I transitioned a 5-series board to UBB.threads about a year and a half ago, and there was much grinding of teeth and complaining about the way things changed. However, people adapted after a week or three, nobody threw a hissyfit and left, and it all turned out well in the end.

At this time, we do not plan a major UI change for the new product - it will look much more like a Classic than a Threads, but it will be comfortable and familiar for both sets of users. (This may change before beta, however. Dave really wants to do something Eve-ish eventually, with the DHTML menus and all that. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" /> )

Also, addressing another concern - how well it can scale.

You mentioned adding another server if that's what it took... well, right now, under UBB.classic, you can't quite do that. We've never found an implementation of NFS that was stable enough to run a highly loaded UBB.classic.

Under the new product, doing that is easy. In fact, it's highly advised for REALLY huge boards to use one machine to host the application and another machine just for the database. For higher scalability, just add more application servers, and more powerful database machines. (Getting MySQL to balance load over multiple servers has been an... interesting task in the past. Their new Cluster product looks promising in this regard.)


Gizzy:
To clarify on this, we are not giving preference to either group of customers.

Untrue. We intend the migration scripts to do everything possible to import all settings and information from UBB.classic, including PMs and styles.

The original Classic->Threads migration script was written by a third party. Due to a number of design decisions, it can't do an effective job at importing quite a bit of the more subtle data that UBB.classic stores. I blame PHP. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" />

The migration script for the new product (from Classic) will be written in Perl and will be designed to operate as a nearly seamless component of the board. It will be able to move everything over, hopefully without a hitch.

Likewise, the migration script to the new product from Threads will be written in PHP, and do the same exact thing for the Threads board - use the internal access routines to move everything over.

That being said, there are some things that won't translate over correctly. We've removed a small handful of features (such as DaysPrune), and changed the way some others work. Logically, we can't import settings for features that aren't there. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" />

Also, UBB.threads defines styles completely through CSS files. There is no portable CSS parser for PHP, so we might not be able to import the fonts and colors found in the available CSS files into the new style system.

Back more direclty addressing the topic...

We are aware that switching to an entirely new product is a daunting task. There will be a big learning curve for the admins, and a moderate learning curve for the end users. We are going to do our best to make sure that the migration goes as smoothly as possible.