These two bytes may not matter to you...

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: These two bytes may not matter to you...
« Reply #15, on August 7th, 2011, 12:55 PM »
A suggestion. Maybe we could store the md5 for all files *minus* the file version (i.e. we take the file, and substr it to after the @version line, or just remove the comments), and check them against the latest database...? That way, we can modify the version number in one go, but if the file contents themselves are the same, we're good to go. Another perk of this would be that if users had their files corrupted at upload time, they'd be noticed immediately.
Of course it can be seen as an annoyance that were the files to be modified by add-ons, we'd never be able to get their proper md5. But maybe it's a path to explore...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #16, on August 7th, 2011, 01:01 PM »
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.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

karlbenson

  • Posts: 44
Re: These two bytes may not matter to you...
« Reply #17, on August 8th, 2011, 06:35 PM »
When writing the smf patches it was always a pain in the backside to have to change the header version no. for every file altered. And often one might get forgotten.

If the version was set at the top of the patch, the program should automatically update the version info at the top without having to code the find/replace statement.
We come in peace, shoot to kill, shoot to kill, shoot to kill; we come in peace, shoot to kill; Scotty, beam me up

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: These two bytes may not matter to you...
« Reply #18, on August 10th, 2011, 10:22 PM »
Wondering about the database tables...
I was looking into them, and found an awful lot of INTs (small, tiny, etc.) that are not unsigned, even though they're assigned to things like id_* where you rarely get a negative number (only on a few exceptions.)
Shouldn't we change these to unsigned...? Or whatever?
Quote from Arantor on August 7th, 2011, 01:01 PM
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.
Yup...
OTOH, maybe files shouldn't get a @version at all, in these conditions. I mean, if we set up a system where users can automatically update their files to the latest version, based on their Wedge version and ours, we don't want them to have files with 'outdated' version numbers. (Of course if we remove the version check, they won't see that in the admin area, but that might still look odd if they open the files manually.)
(Or we just don't care and leave files with their old version numbers.)
Quote
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.
Hmm... Could be doable.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #19, on August 10th, 2011, 10:28 PM »
Quote
Shouldn't we change these to unsigned...? Or whatever?
If we can guarantee we never need an unsigned value, we can use that. However int is problematic because unsigned int is an unsigned 32 bit value which runs over the limit of PHP at times (and can be silently switched for a float)

Tinyint, smallint and mediumint can all be safely made unsigned if the values never go negative.
Quote
OTOH, maybe files shouldn't get a @version at all, in these conditions
It can be useful but if you're not offering patches it's almost not worth the effort. More thought needed.

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: These two bytes may not matter to you...
« Reply #20, on August 11th, 2011, 04:08 PM »
Working on a lot of JavaScript optimizations right now...
I think that the editor code (in the HTML) should be tighter. Not that it's going to change anything on compressed files, but if for any reason your server is not sending gzipped data, I've found that my optimizations, while not changing anything to the feature set, actually saves over 3KB... That's not a bandwidth saving I'm going to laugh at, really.

I'm having a couple of issues with one thing though... SMF/Wedge always define images_url in the HTML JS. In Wedge, it is we_images_url. It is only used 3 or 4 times in the entire code, and never for interesting things.
I've been looking at the code for $settings['images_url'], and I can't find any place where it is set to anything else than $settings['theme_url'] . '/images'.
So, my question would be... Can't we just print the we_theme_url variable, and add /images/ to it when needed?
I'm just worried it could be set at some point to $settings['default_theme_url'] . '/images', but I couldn't find it. (I have to say, I'm drowing in micro-optimizations right now... Big commit coming up, eh.)
Quote from Arantor on August 10th, 2011, 10:28 PM
If we can guarantee we never need an unsigned value, we can use that. However int is problematic because unsigned int is an unsigned 32 bit value which runs over the limit of PHP at times (and can be silently switched for a float)
Never heard about that... But yeah, I figured the signed stuff must be an oversight on the SMF devs' part.
However, I don't feel like checking all INT entries and adding unsigned to them, so if you're not interested with the idea, I guess we can simply forget about it, at least for now...
Quote
Tinyint, smallint and mediumint can all be safely made unsigned if the values never go negative.
Alrighty.
Quote
Quote
OTOH, maybe files shouldn't get a @version at all, in these conditions
It can be useful but if you're not offering patches it's almost not worth the effort. More thought needed.
Not worth adding @version to all files, or not worth removing it...?

I don't think the actual @version string is of any interest, whether in the program or legally.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #21, on August 11th, 2011, 04:20 PM »
Quote
I'm just worried it could be set at some point to $settings['default_theme_url'] . '/images', but I couldn't find it. (I have to say, I'm drowing in micro-optimizations right now... Big commit coming up, eh.)
I know there's a point where the theme details are temporarily switched with another details but I can't remember if it was done on the theme URLs or something else (like the theme directories)
Quote
So, my question would be... Can't we just print the we_theme_url variable, and add /images/ to it when needed?
The idea is that you could have a theme whose image folder is something else but the reality is that theme never specifies an actual folder AFAIK (at least not in its own theme-info.xml), but there is a setting actually stored for it.
Quote
Never heard about that... But yeah, I figured the signed stuff must be an oversight on the SMF devs' part.
However, I don't feel like checking all INT entries and adding unsigned to them, so if you're not interested with the idea, I guess we can simply forget about it, at least for now...
I don't recall there being any performance issues with it, so I'm not that bothered with fixing it right now, but at some point if we get bored...
Quote
I don't think the actual @version string is of any interest, whether in the program or legally.
If we're not providing patches, there isn't really a great deal of good reason to leave the version number in the files, per se - but there may be a reason that hasn't occurred to us yet to leave them in.

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: These two bytes may not matter to you...
« Reply #22, on August 11th, 2011, 04:28 PM »
Quote from Arantor on August 11th, 2011, 04:20 PM
The idea is that you could have a theme whose image folder is something else but the reality is that theme never specifies an actual folder AFAIK (at least not in its own theme-info.xml), but there is a setting actually stored for it.
I think it should go, then.
I'm okay with themers and modders being given abilities to do plenty of things that aren't by default in SMF/Wedge.
It's another thing when you start offering features that they have absolutely no reason to use.
For instance -- if they want to put their image folder into a separate (cookieless) subdomain, it's something that can be done without any changes. You just point the subdomain to that folder... It's what I used to do for Noisen (until I decided I was bored of paying $10/y for a domain name I only used to redirect to static content :P)
Quote
I don't recall there being any performance issues with it, so I'm not that bothered with fixing it right now, but at some point if we get bored...
It's not about the performance, rather about doubling the amount of IDs you can suddenly start using...
Quote
If we're not providing patches, there isn't really a great deal of good reason to leave the version number in the files, per se - but there may be a reason that hasn't occurred to us yet to leave them in.
I'll give you some time to think about it :P

Even if we provide automatic updates through the website, I don't see anything that would require having a version number.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #23, on August 11th, 2011, 04:38 PM »
Yeah, I guess that makes sense when put like that about the theme dir; but it's something that most people won't ever realise they can do - even if it's something that would be pretty useful in the scheme of things.

That said, there are places in the code that do make the assumption that images_url is just theme_url with /images/ after it, so it wouldn't be a bad idea to make everything consistent - but switching it to use theme_url with images consistently isn't a bad thing, because you can still do that sort of thing; you can move the entire directory for a given theme (sans PHP files) to a separate URL for that reason and just update theme_url.
Quote
It's not about the performance, rather about doubling the amount of IDs you can suddenly start using...
I have seen the grand total of one SMF forum that broke through the signed barrier on int columns for the messages table and only then through a serious amount of bad luck and sheer incompetence, and no instance of SMF that broke the topics table limit. 8 million topics and 2 billion posts is a massive scale.

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: These two bytes may not matter to you...
« Reply #24, on August 11th, 2011, 04:49 PM »
So... Is that a yes as to whether I can use theme_url + /images/? :P
We may want to document that... And maybe simplify the code later on, to ensure we don't go through extra lines of code when we could do things simpler. (More simply... Simplier? Why does my spellchecker underline that word? Heck, why does it underline spellchecker, too? :P)

As for topics and posts, no doubt this should be enough, but I was thinking more about the 'smaller' IDs, like tinyints and smallints, really... Even mediumints are not that worthy of attention.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #25, on August 11th, 2011, 04:50 PM »
Quote
So... Is that a yes as to whether I can use theme_url + /images/?
Yes, I think so, since separate subdomain etc is still supportable through that.
Quote
More simply... Simplier?
Simpler ;)

Nao

  • Dadman with a boy
  • Posts: 16,063

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,063

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278