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
3406
Features: Posts & Topics / Re: Likes
« on May 17th, 2012, 03:16 PM »
Of course we can :) I'm just not sure we need it at this point in time ;)
3407
Features / Re : Rewriting the skin file parser...
« on May 17th, 2012, 03:16 PM »
Well, here's the thing, and it's actually the source of some of the 'SMF 2 is slower than SMF 1' theory. It's also incredibly complicated, but bear with me and hopefully I'll explain how it all works.
SMF 1 has no file cache. Thus no queries get cached to files but it can use proper caches like memcache. That means until such times as you're on a grown up cache, you're swallowing the extra load attached to all the uncached queries.
The difference as compared to SMF 2 is though, when you're starting out, the cache miss frequency will be much higher due to low traffic, so in starting out (and, unsurprisingly, prime shared hosting territory) you're not only not benefitting much from the cache because it expires too quickly for the low traffic, you're also paying the overhead attached to it too.
So at the very earliest stages, you carry out extra work compared to SMF 1, and see little benefit - but as soon as you start getting anywhere serious (and by that I mean you start getting any real volume of traffic), the cache soon starts to kick in and benefit, and I suspect the reality is that you'd be able to run SMF 2 on shared hosting longer than you would for SMF 1 because of the caching taking the edge off the DB, and especially that most hosts target CPU as the prime measure of load and don't focus on I/O, so the cache definitely helps there.
I think the file cache is worth doing. The problems with the cache subsystem as they stand are:
1. It's totally I/O bound. As nend's experiments show, there's little you can do to optimise that. So the speed benefit is finite. There are advantages to using the SQLite system as nend suggested, though.
2. Things are not best using the cache, but that's not systemic to the cache itself; the fact $settings is not cached by things other than the file cache is not the fault of the file cache, it is the fault of the housekeeping that drives all of the caching system. Transferring the cache settings to be in Settings.php means it's possible to cache $settings, something not possible in Wedge currently except through the file cache (which is better than nothing)[1]
3. Clearing the non-file caches is difficult and unreliable. Clearing the file cache or even parts of the file cache is trivial by comparison.
Re the menu, the big problem there is the fact that changing the rest of the layout screws other things up too, which is a big con in my book. I know only too well that resizing the browser or other layout causes a lot of hassle when positioning is important (especially if the size of menu panels is dependent on the layout of the screen!) but to me that seems a deal breaker, especially as the complexity of fixing it by binding to the viewport's resize is going to add a fair bit more code.
SMF 1 has no file cache. Thus no queries get cached to files but it can use proper caches like memcache. That means until such times as you're on a grown up cache, you're swallowing the extra load attached to all the uncached queries.
The difference as compared to SMF 2 is though, when you're starting out, the cache miss frequency will be much higher due to low traffic, so in starting out (and, unsurprisingly, prime shared hosting territory) you're not only not benefitting much from the cache because it expires too quickly for the low traffic, you're also paying the overhead attached to it too.
So at the very earliest stages, you carry out extra work compared to SMF 1, and see little benefit - but as soon as you start getting anywhere serious (and by that I mean you start getting any real volume of traffic), the cache soon starts to kick in and benefit, and I suspect the reality is that you'd be able to run SMF 2 on shared hosting longer than you would for SMF 1 because of the caching taking the edge off the DB, and especially that most hosts target CPU as the prime measure of load and don't focus on I/O, so the cache definitely helps there.
I think the file cache is worth doing. The problems with the cache subsystem as they stand are:
1. It's totally I/O bound. As nend's experiments show, there's little you can do to optimise that. So the speed benefit is finite. There are advantages to using the SQLite system as nend suggested, though.
2. Things are not best using the cache, but that's not systemic to the cache itself; the fact $settings is not cached by things other than the file cache is not the fault of the file cache, it is the fault of the housekeeping that drives all of the caching system. Transferring the cache settings to be in Settings.php means it's possible to cache $settings, something not possible in Wedge currently except through the file cache (which is better than nothing)[1]
3. Clearing the non-file caches is difficult and unreliable. Clearing the file cache or even parts of the file cache is trivial by comparison.
Re the menu, the big problem there is the fact that changing the rest of the layout screws other things up too, which is a big con in my book. I know only too well that resizing the browser or other layout causes a lot of hassle when positioning is important (especially if the size of menu panels is dependent on the layout of the screen!) but to me that seems a deal breaker, especially as the complexity of fixing it by binding to the viewport's resize is going to add a fair bit more code.
| 1. | I'm still floating on whether this particular measure is ideal or not. It does make it a shade harder to force flush the cache because the time of last settings update is also in the settings table (and there is no safe way to put it anywhere else) |
3408
Bug reports / Re: SMF bug 4905 (signature length verified before preparsecode)
« on May 17th, 2012, 01:10 PM »
Our changelogs don't just have SMF bug fixes in though and it can be easy to miss 'em.
3409
Features / Re : Rewriting the skin file parser...
« on May 17th, 2012, 12:57 PM »After SMF 2.0 you mean?
3410
Features: Posts & Topics / Re: Likes
« on May 17th, 2012, 12:56 PM »
Well... if it's being done for sorting, it makes no difference whether a given person's is in there or not, since you'd just be sorting based on the like count of a topic.
I didn't bother putting it there since I didn't really see that much of a use for it at that level...
I didn't bother putting it there since I didn't really see that much of a use for it at that level...
3411
Features / Re: User configurable CC email accounts
« on May 17th, 2012, 12:38 AM »
So the problem therein becomes 'how do we allow multiple people on a single ticket', which is still a problem to be solved at the helpdesk level - or done through some kind of parent/child relationship for accounts. At least, that's my take on everything that's been said thus far.
3412
Features / Re: User configurable CC email accounts
« on May 16th, 2012, 07:25 PM »
Here's the thing though, I simply cannot in good conscience implement CC lists as you're proposing into Wedge in any form. To me, the privacy aspects attached to it make it unworkable, not to mention all the actual consequences of doing so, namely that announcements, PM notifications and indeed any other notifications get cascaded through the system, including screwing up the mail queueing architecture - meaning that instead of having it 'merely CC' is not workable at all and would be better served as putting each unique email as an item in the queue.
From a pure programming perspective, it would actually be easier to serve the whole setup (including the security architecture of SimpleDesk) as parent/subaccounts and be done with it.
From a pure programming perspective, it would actually be easier to serve the whole setup (including the security architecture of SimpleDesk) as parent/subaccounts and be done with it.
3413
Features / Re: User configurable CC email accounts
« on May 16th, 2012, 06:28 PM »
I realise that, but as I'm sure you also realise, my requirements in solving a problem are to solve the problem in its entirety, and I'm not sure what you're asking for is something that I want to put in Wedge's core, primarily because I think it's solving the symptoms of your problem, not your actual problem.
There are all kinds of issues attached to a CC list plugin, not least privacy.
Why would group ownership of resources be a can of worms, exactly? Seems to me that the ideal solution is to be able to define an account as being a child of another account.
There are all kinds of issues attached to a CC list plugin, not least privacy.
Why would group ownership of resources be a can of worms, exactly? Seems to me that the ideal solution is to be able to define an account as being a child of another account.
3414
Off-topic / Re: Bitcointalk.org $11k bounty for new forum software
« on May 16th, 2012, 06:24 PM »
I think you're missing the point, though.
What is currency? How does currency work? Well, go back to ye olden times, you had goods exchanged between people, a butcher might trade his meat with a farmer for grain. In order for that to work on a larger scale, currency was invented as a form of IOU to enable transactions without having to cart around the physical goods.
The kicker, of course, is that the currency is worth what it's worth - and its worth is usually determined by governmental issue; governments printing more cash at a colossal scale causes hyperinflation and the currency stops being worth as much.
Now, with Bitcoins, the whole point is that it's decentralised. While that seems wonderful for the sorts of folks that need it, it really isn't. Even if we take the assumption that a Bitcoin is a tradeable commodity, it suffers from all the same supply and demand logistics that apply to any other commodity, namely that the price a given market will pay based on available supply and demand.
Money, or more specifically currency, is a commodity - the value of money is depending on the supply (from the government) and demand (people spending). Create more money in the economy, supply goes up, demand doesn't increase so fast, the money devalues.
Bitcoins have this exact problem: they're a toy currency. The amount of exchangeable currency available is a product of supply and demand, and the demand for Bitcoins is constrained, while supply is far less so, so over time the value will deflate. That aside, you still have to exchange it for currency, meaning that you're trying to convert a series of numbers into real currency - but I don't see much happening the other way.
Conceptually, what is the difference between buying Bitcoins and buying Facebook Credits, outside of the fact that FB credits are only spendable via FB?
What is currency? How does currency work? Well, go back to ye olden times, you had goods exchanged between people, a butcher might trade his meat with a farmer for grain. In order for that to work on a larger scale, currency was invented as a form of IOU to enable transactions without having to cart around the physical goods.
The kicker, of course, is that the currency is worth what it's worth - and its worth is usually determined by governmental issue; governments printing more cash at a colossal scale causes hyperinflation and the currency stops being worth as much.
Now, with Bitcoins, the whole point is that it's decentralised. While that seems wonderful for the sorts of folks that need it, it really isn't. Even if we take the assumption that a Bitcoin is a tradeable commodity, it suffers from all the same supply and demand logistics that apply to any other commodity, namely that the price a given market will pay based on available supply and demand.
Money, or more specifically currency, is a commodity - the value of money is depending on the supply (from the government) and demand (people spending). Create more money in the economy, supply goes up, demand doesn't increase so fast, the money devalues.
Bitcoins have this exact problem: they're a toy currency. The amount of exchangeable currency available is a product of supply and demand, and the demand for Bitcoins is constrained, while supply is far less so, so over time the value will deflate. That aside, you still have to exchange it for currency, meaning that you're trying to convert a series of numbers into real currency - but I don't see much happening the other way.
Conceptually, what is the difference between buying Bitcoins and buying Facebook Credits, outside of the fact that FB credits are only spendable via FB?
3415
Features / Re: User configurable CC email accounts
« on May 16th, 2012, 06:14 PM »
I get that, but on the other hand, it still doesn't seem right to me. The proper solution, from my perspective, would be to create a real account per user and make them members of a given group that allowed them access. I'm always wary about group shared accounts for anything.
The problem as I see it is that you're looking to solve one problem with a workaround, rather than solving the entire problem in its entirety.
The problem as I see it is that you're looking to solve one problem with a workaround, rather than solving the entire problem in its entirety.
3416
Features / Re: New revs - Public comments
« on May 16th, 2012, 06:12 PM »
Searching on a serialised array is not unheard of. I just got really confused with what the search was trying to do, since it looked to me like it was searching for the string itself, not for the id for it.
3417
Archived fixes / Re: Long cache keys make the cache fail.
« on May 16th, 2012, 06:11 PM »
The biggest delay in the file cache, really, is the physical I/O on it, everything else is going to be a push depending on everything else going on all the time; SQLite typically has more going on with respect to CPU overhead but that's invariably worn down by the I/O overhead.
It's certainly been an interesting journey and I'm sorry to hear that you weren't able to get somewhere really interesting, but this strikes me as something that isn't quite in the scope of SQLite, though I'm not sure what scope SQLite has on the server anyway. (For embedded databases or uses like the history in Chrome, I can understand it, but not on the server as a poor man's MySQL.)
It's certainly been an interesting journey and I'm sorry to hear that you weren't able to get somewhere really interesting, but this strikes me as something that isn't quite in the scope of SQLite, though I'm not sure what scope SQLite has on the server anyway. (For embedded databases or uses like the history in Chrome, I can understand it, but not on the server as a poor man's MySQL.)
3418
Features / Re: User configurable CC email accounts
« on May 16th, 2012, 05:58 PM »
Interesting, though I'm not sure whether this should be solved at the Wedge level or the helpdesk level. It seems to me that as it's the helpdesk generating the emails, it should be the helpdesk that's responsible for managing multi-addresses.
Would you want, for example, password change emails to go to all of the email addresses?
Would you want, for example, password change emails to go to all of the email addresses?
3419
Off-topic / Re: Bitcointalk.org $11k bounty for new forum software
« on May 16th, 2012, 05:49 PM »
What charm and place in society?
The idea of a virtual currency based on CPU time is totally unworkable. (In a former life I studied economics. It has no viable economic basis.)
The idea of a virtual currency based on CPU time is totally unworkable. (In a former life I studied economics. It has no viable economic basis.)
3420
Plugins / Re: Crazy plugin-related idea I just had
« on May 16th, 2012, 05:11 PM »
Actually, I realised today that I pretty much need to do validation of tags at the first-child level.
Consider the bbcode support I added, and now assume for the sake of argument that I implemented that in Wedge 1.1. Plugins that were written for 1.1 would install successfully (as far as plugman cares) on 1.0 but the bbcode wouldn't work. There isn't a safety net there to validate that it works, and plugman does not fail visibly on most things, it just ignores them (which is probably a safer way to go about things, though it isn't helpful for debugging much)
Anyway, here's the plan. First level validation needs to occur for general support, and that is what gets extended by plugins that declare their own XML blocks. This does also provide for a certain level of safety in terms of plugins - should I add sections, later plugins won't be installed on earlier versions. (And if people hack the plugin-info.xml file, it isn't going to work properly anyway, heh)
Consider the bbcode support I added, and now assume for the sake of argument that I implemented that in Wedge 1.1. Plugins that were written for 1.1 would install successfully (as far as plugman cares) on 1.0 but the bbcode wouldn't work. There isn't a safety net there to validate that it works, and plugman does not fail visibly on most things, it just ignores them (which is probably a safer way to go about things, though it isn't helpful for debugging much)
Anyway, here's the plan. First level validation needs to occur for general support, and that is what gets extended by plugins that declare their own XML blocks. This does also provide for a certain level of safety in terms of plugins - should I add sections, later plugins won't be installed on earlier versions. (And if people hack the plugin-info.xml file, it isn't going to work properly anyway, heh)