Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arantor
6781
Features / Re: These two bytes may not matter to you...
« on August 11th, 2011, 05:24 PM »
Quote
Then what's the short form of 'more simple'?
Simpler.
6782
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 05:24 PM »
That wasn't my example :P

My example specifically had post 1 owning post 2 owning post 3 etc.
6783
Features / Re: These two bytes may not matter to you...
« 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 ;)
6784
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 04:48 PM »
It is another thread, but it's older than the post 3/4 thread, so I still don't see why it would become further down the chain - doubly so if you're merging the posts?
6785
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 04:38 PM »
Quote
No...? Because we wouldn't be merging the posts physically. That's exactly the point. If you're in threaded mode, you'll see Post 2 after Post 4 in that hierarchy, and in flat mode, you'll see posts 1 & 2 together.
Why? That's my point. Post 2 came before post 3 or 4, why would it be after?
6786
Features / Re: These two bytes may not matter to you...
« 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.
6787
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 04:25 PM »
Quote
Oh, that sounds messy to me... How so? [merge id=12345 date=67890]?
Yup. Then when you de-merge the post, you insert a new row in the messages table with id 12345. Then again, not recommended for InnoDB which will cause trouble since it'll force the entire messages table after that point to be rewritten.
Quote
Heck, I don't even think we can insert a message ID and set the id_msg manually. It'll always rely on autoincrement
Yes you can, it works as you'd expect: supply an id and it'll use it, don't supply it and you get the benefit of auto-increment.
Quote
Err... No?
So...

Post 1 by Arantor
  Post 2 by Arantor
  Post 3 by Nao
    Post 4 by Nao

If you merge posts 1 & 2, surely you'd end up with:
Post 1 & 2 by Arantor
  Post 3 by Nao
    Post 4 by Nao
Quote
(Whether or not we should show "by Nao" on Post 4 in threaded view is something we'd decide later on, depending on the layout and design.)
This is the bit I'm referring to.
Quote
I'd like to know our users' opinion on this.
Sure thing :) That's part of the reason I'm not entirely against the idea.
Quote
We can always add a profile setting to view posts as a single one, as a series of separate posts, or as an in-between version with posts merged together but all buttons available for all posts.
Works for me :)
6788
Features / Re: These two bytes may not matter to you...
« 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.
6789
Features / Re: Bookmarks
« on August 11th, 2011, 02:37 PM »
Quote from Aaron on August 11th, 2011, 02:34 PM
Quote from Arantor on August 11th, 2011, 01:48 PM
I have to admit I actually had a different idea for tracking topics of interest that wasn't really related to the notifications system.
I'd be interested to hear it, really. :) (Perhaps I've missed a topic?)
Can't remember where I talked about it but I suggested a table that records user/topic/relationship, where you could track user bookmarks, plus ignored topics which means you could then do all kinds of useful joins on it.

You could also then replace the participation index on the messages table with a row in this table, so that you can make things a little faster than making use of that other index.
6790
Off-topic / Re: To fork or not to fork - in other words: Hi :)
« on August 11th, 2011, 02:19 PM »
I have seen animated icons - and of course there are animated smileys, which I think would be pretty awkward for spriting.
6791
Features / Re: New revs
« on August 11th, 2011, 01:59 PM »
Revision: 922
Author: arantor
Date: 12:58:49, 11 August 2011
Message:
! Mismatched tags in the who's viewing sidebar template in message index. (MessageIndex.template.php)

! Time to be controversial; removing meta keywords. Most forums have them turned off, the ones that don't have global keywords that don't help, and major search engines don't use them anyway, so it's actually work that isn't needed. (Subs.php, ManageSettings.php, index.template.php, ManageSettings and Help language files)

! Added general facility for meta description support, now to be used in the message index and more places in future. (index.template.php, MessageIndex.php)
----
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/MessageIndex.php
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Themes/default/MessageIndex.template.php
Modified : /trunk/Themes/default/index.template.php
Modified : /trunk/Themes/default/languages/Help.english.php
Modified : /trunk/Themes/default/languages/Help.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
6792
Features / Re: Bookmarks
« on August 11th, 2011, 01:48 PM »
I have to admit I actually had a different idea for tracking topics of interest that wasn't really related to the notifications system.

I'm still not entirely sold on the whole social bookmarks thing, even though xenForo actually goes as far as putting them in the SEO configuration page, on the theory that Google's +1 and others are actually used by search engines for ranking purposes.
6793
Features / Re: Bookmarks
« on August 11th, 2011, 01:35 PM »
What do you mean by internal bookmarks?

I thought about social bookmarks but not really convinced about it just yet.
6794
Features / Re: Blogging features
« on August 11th, 2011, 01:25 PM »
So you're going to build a whitelist of such sites? Or a blacklist of sites you don't want? Either way the methodology is a bit flawed.

There is a module in Bad Behaviour for trackback posting, but it's not bulletproof - but the referer is not generally supplied, even in spam cases.
6795
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 12:51 PM »
Quote
Hmm... But you'd have to create new posts to accommodate for that, and you know what happens with old posts that have a higher ID...
Store the original id; when it's reinserted it will take its original place.
Quote
I don't see where?
With a single post being formed, any threaded replies would also be merged into that branch. If you retain the two posts, you have to figure out how the final thread would be shown.
Quote
Because it doesn't delete the old post anyway, right? If that's true then the new solution would actually be better...
It probably would make a little difference, but I wasn't pointing it out as a pro/con, more that it can make a difference that shouldn't be forgotten.
Quote
Are you sure?
To me I think of posts as atomic items and merging double posts does seem logical to make the result atomic.

The whole double post thing isn't just about dealing with the signature and avatar and so on... it's also about keeping it a single post, in terms of management, in terms of replying to it, splitting and so on. I can see the wisdom of being able to split two merged posts, but at the same time I'm not keen on it looking like two posts; if I merge two posts I want one physical post.

Let's just say for now that I'm not against the idea but I'm not entirely sold on it yet.