Wedge

Well, I'd upgrade to 2.0 final anyway knowing as I do that there are security related issues in RC3 that have been addressed by 2.0 final...

To be honest, though, there are no major DB changes between RC3 and final so the process should be virtually identical anyway from an import point of view; of course if the structure's been modified through mods, your mileage can and will vary.

That's the point, it's all a matter of irony ;)

r913 is something I had been planning to do a bit back but what always stopped me is the type conversion because I wasn't sure what the upper bounds of anything were supposed to be.

It may be version specific but int(4) should do something different to tinyint(4) - in theory, an int(4) should consume at least twice the space of a tinyint(4) and potentially quadruple it; int defines a 4 byte integer, tinyint a 1 byte integer, but even if MySQL is a bit smarter, and assumes the number as a size of digits, you still have to allocate two bytes (i.e. a smallint) because a potentially-4 digit number is invariably going to consume more than one byte. (The reason tinyint defaults to 4 is because of the leading sign, e.g. -127)

I don't believe MySQL uses that value for type hinting though, because of the above fact that it could be unreliable, meaning that I think it's always going to allocate 4 byte integers for everything even if it's only a one byte column, so it might be worth glancing through the code sometime to see if we do actually need 4 byte ints everywhere, since I'm not sure.

In other news, at some point we need to make sure that the list of tables that we end up with is in the listed of reserved tables in the DB class(es).

I'm inclined not to bother; the more I think about my experiences supporting SMF, the more I was inclined not to ever ask for it when provided simply because I don't think it made a lot of difference.

It's only really useful in the core if we provide patches, I think, and if we don't provide patches there's not a lot of value in keeping the complete list of files and versions (or signatures) - not in the core anyway.

That said, there is the validity of providing such for part of a diagnostic tool, but then you'd probably want to keep all the different versions then but not in the core, and it could flag up that a file has been changed.

In fact, could go one step further - as part of an add-on's install if it requires (and is permitted to perform) raw edits, we could do md5 before and after and store that somewhere so that we do have the signature available for testing.

But I think we can ditch it from the core to be honest. It's less code there that's really going to help us.

With so many options, there needs to be a way to shortlist some of them to cull the list to a manageable size.

Perhaps break them into groups by general style, then see which one of those is most favoured.

You can allow people to pick 3 in a regular poll but it'd be huuuuuuge.

Sorry, been limited on internet today.

I believe version emulation is the reason for it, that it has to be in a variable in order for it to work as currently implemented, plus the old copyright check.

I agree that just storing the version number (i.e. 0.1) in the constant is all that's actually needed, and we can insert 'Wedge' into the copyright string itself normally.

I'm still not convinced that constants are slower than variables, the only evidence I've seen for that is a claim to that effect without any real benchmarking to prove it, and even my own limited benchmarks don't seem to validate it being slower - if you're not throwing it around between scopes, and referencing it in only one major place per page load, the saving of not declaring both a variable and a constant should outweigh any performance issues from a constant, especially since that's the ideal context for using such a thing...

Or you could do what I did; remove the Comic Sans font and replaced it with a separate font instead - a long time ago I butchered Arial Bold and make it have the Comic Sans name, consequently I just have anything in "Comic Sans" turning up in a less hideous font, but the fact it's bold tells me that it's not just what it seems to be ;)

Comic Sans has a place, but it's clear that a lot of people reeeeeeeeeally hate it - http://bancomicsans.com/