UDWiki talk:Open Discussion/ParserFunctions extension

Notice

This is NOT a policy discussion. This is an Open Discussion about an issue regarding the wiki. Please treat it as such and contribute with that in mind.

Nothing really formal here. If the point you want to argue doesn't have a header yet, just hit the "+" tab and list a new one.

Server Load

I have no real clue here: how much server load would the extension cause? Wouldn't the improvement of widely used templates such as Template:Ifdef and and the like have a significant beneficial impact? What about the reduction in manual edits required by pages such as List of Revivification Points, or the NT Status Map (all updates to this page could be automatic, with ParserFunctions and moving status variables to the various DangerReports themselves)? Where is the balance likely to fall with the UDWiki? --Morgan Blair 05:48, 17 May 2008 (BST)

It would cause a lot. There is a significant difference in CRUD operations to the DB (saves/edits) than live-time CPU processing of templates and scripting. An *insane* difference.
This may be a "labor saving device" for some people but I don't think it's needed, as we all know the only reason people want it on the wiki is to make their inane signature templates even more inane.
Thus, little-to-no value.--Jorm 21:54, 17 May 2008 (BST)

"We all know" the utility value far offsets the likely server load, and server power gets cheaper over time. Of course if you don't plan to use it or look at any pages it is used on it has no value TO YOU. As for sigs- meh, a simple policy banning their use in sigs (as we do for over-sized images already) would cover it, if that is an issue.  Swiers 00:50, 18 May 2008 (BST)

Are you seriously saying that Kevan should buy a new server to support your little hobby code?--Jorm 03:14, 18 May 2008 (BST)

Of the six people who have previously expressed a support for the extension, two don't even use a templated signature, and the other four have signatures even less flashy then mine and Swiers, so I think your comment in that regard was completely out of order... --Morgan Blair 07:38, 18 May 2008 (BST)

Are you seriously saying that Kevan should buy a new server to support your little hobby code? Is that seriously what you think I was saying?
Given a total absence of hard facts, I'm making a judgement based on global conditions. Maybe Kevan leases server access, and it will (or won't) get upgraded whatever he does. Maybe if he owns one, he plans to replace or extend it any how. If you are privy to actual technical details, please give them as reasons, not vague assessments like "insane" and "we all know".
Also, from what I know, bussiness logic is actually the LEAST lag producing of server functions; DB connections and file access are exponentially slower. So what actual impact would "live-time CPU processing of templates" on a fraction of pages have, even if it creates a "significant difference"?
Besides, when I really want to do hobby coding, I pay for my own server  Swiers 08:26, 18 May 2008 (BST)

I'm running this wiki on the same server as a lot of other sites and projects, which would be affected if the wiki were permanently running at a significantly higher level of server load (it's already suffering a bit from the disk space required for MediaWiki's copious archives). And yes, it would cost me money if I wanted to upgrade the machine.

I'd like to make life easier for the status-page editors, but as Jorm suggests, once ParserFunctions are available they're inevitably going to creep out into other templates, and this is a wiki where a lot of people aren't even subst'ing their signatures. It wouldn't be very easy (or much fun) to try to police where ParserFunctions could and couldn't be used.

I'm open to trying ParserFunctions out, but wouldn't want to waste everyone's time if I had to shut them down again three months later because of the server load. --Kevan 09:25, 18 May 2008 (BST)

Prehaps some sort of test might be in order, could we not try converting one well used page and its templates into versions with the extra functions and take a look at how long it takes for the server to serve the page before and after over the period of a week or so? If there appears to be a large increase that, when multiplied by the other pages we would want to use the functions on, was too large then we could switch back to the system already in place and disable them again. I'm not sure how accurate such a test would be, I'm no web guru, but hard results would be better evidence then wading about in conjecture. --  RoosterDragon  11:41, 18 May 2008 (BST)

It's not the server load of specific, well-used pages I'm concerned about, it's the total server load of however many random pages and templates and signatures end up using ParserFunction calls, when they become available to everybody. We can't multiply a single example without knowing the number to multiply it by. --Kevan 19:35, 18 May 2008 (BST)

When someone says "server power gets cheaper over time", what they are saying is "the hardware can or should be upgraded to compensate for additional load." Hence, you're saying, "Kevan should upgrade his server so we can use the Parser code if it can't support it already."
I don't have any specifics about the hardware but I can tell you that upgrading servers - especially hosted ones - is an expensive process. Because, you know, this isn't my first rodeo, and I know a bit about these things.
You are correct in that the hardest performance hit in any application comes from database access (alleviated somewhat in well written applications with solid ORM or even Connection caching, but MediaWiki is php, so there goes that) - but you see, we are already dealing with those performance hits. They're already there; what you are suggesting is increasing the load.
God help us all if it takes parsing functions into account when it runs indexes. That's already a crippling event.

(Also: out of order comment my ass.)--Jorm 17:54, 18 May 2008 (BST)

Well, I suppose we could test it by having one of those people who can make bots make one to change all the "Ifdef" template calls with "#Ifdef" (I'm assuming it could be swapped in that manner), and then let the wiki run like that for a week, Keven would be able to get a fair idea of the impact. Would this be feasible? --Morgan Blair 18:58, 18 May 2008 (BST)

For clarification, I suggest testing "Ifdef" because it's being used over 2000 times on the wiki already, and shows up in so many widely accessed pages, that it's likely to have a significant enough impact on it's own and be somewhat representative. As for parser functions showing up in signatures, that should be outright banned... --Morgan Blair 21:08, 18 May 2008 (BST)

That's kinda pointless for the sake of making a point when parser functions are something that should be used in an as needed basis, the "most needed" parser function isn't a Switch of If one so much as Expressors, ways to compare and calculate values, the closest we currently have is {{Switch}} and that comes extremely short.--Karek^maps?! 10:51, 19 May 2008 (BST)

Okay, well then, how about putting a dummy comparison of dates into the BuildingStatus template? It would be the same calculation being performed everywhere it was called, but I expect that it would cause the same amount of server load as if it was comparing dates from the DangerReports themselves...

I went searching for data on the whole issue (didn't really learn much), but found this on Wikipedia:

Schemes using layers of nested templates to mimic conditional expressions — to selectively hide or show text or images based on the parameters which have been set - are sometimes created by users who are unfamiliar with the better alternatives. Conditionals should generally be avoided, unless there is a significant advantage in their use. If they must be used, then the following methods for conditional logic are available and highly preferred over using nested templates:

• m:ParserFunctions -- Provides a framework for conditional statements within templates. Since it is built into the MediaWiki code, it is relatively efficient on the back-end, but can be very complex for non-technical editors.

Now, this was from a controversial page regarding the proposed "Avoid using Meta-Templates" policy, but as the controversy was about it being a policy instead of a guideline, I believe the actual text I quoted was undisputed. Of course, I'm not sure how meaningful the opinion is in our case, considering the comparative size of that wiki. Remember, I'm not one of you technical-types, just an end user, so don't deride me if I'm being completely clueless, here! --Morgan Blair 19:01, 19 May 2008 (BST)

Vandalism

It's been said (so I hear), that the use of ParserFunctions would open up avenues for vandalism both "exciting" and "new". Maybe I'm just not very vandal-minded (I'm pragmatic—not clever), but I haven't the foggiest as to how likely and/or problematic this would be. What are the dangers, and how difficult would they be to combat? --Morgan Blair 05:57, 17 May 2008 (BST)

I can't see any huge dangers. For the effects to apply, the template needs to be edited onto a page. If its a malicious / bad faith edit, that's vanadalism. The fact that the templates are "smart" might make them harder to detect (you could probably make a template that only causes damaging results intermitantly, or maybe when viewed by specific users) but I expect that's all. I suspect what people would worry about is vandalism of templates themselves, to cause bizarre behavior. Vandalism of widely used templates is already a serious threat, but (thankfully) seems rare.  Swiers 20:22, 17 May 2008 (BST)

"Why fix what ain't broke?" vs. Laborsaving Benefits

Whats so wrong with the wiki that addin this whosit would be a good idea? Making dynamic templates? Whats so good about that? I like the wiki the way it is, hell i just finally got the hang of it, and frankly Kevan has point that vandals would likely love this doohickey. The wiki is supposed to be hard, it keeps the riff-raff out. --Bullgod 06:41, 17 May 2008 (BST)

Wow, you can nay-say with the best of them, Bullgod! While I disagree with your closing point (to say nothing of the ones that preceded), I have to say that it's really unwarranted in this case: while the use of parser functions would enable things that are currently difficult/impossible, I would hardly classify them as being "easy"—at least, I highly doubt that their availability would encourage "riff-raff"... --Morgan Blair 06:58, 17 May 2008 (BST)

If you've ever tried to make a large scale project on the wiki, well, it is in fact broken. I don't see how parser functions make vandalism easier, I can, however, see how it would make reverting it easier while at the same time making large scale projects like the Danger Map or SIM less of an insane hassle.--Karek^maps?! 07:23, 17 May 2008 (BST)

I agree. The amount of manual updating needed for these things is just unbelievable. The Danger Map, Building Information Centres, Recruitment, SIM, Revive Points. All these require some poor sod to give up a huge chunk of their lives just to change the status of them. If we had something to make it easier then that would be rather good. -- Cheese 09:32, 17 May 2008 (BST)

pretty much as the cheese on this one. He's listed off all the uses of laboursaving i thought of. Anyone want to pipe up for the downside? as im well behind this. --Rosslessness^{Want a Location Image?} 14:14, 17 May 2008 (BST)

it's a shame that this wiki lacks parser functions. I'm all in favor of having them, as it would allow to improve even further the already existing systems we already have, and create new ones that weren't possible because of it's lacking, of course. --People's Commissar Hagnat ^{[cloned] [mod]} 17:13, 17 May 2008 (BST)

I don't think anybody could soundly argue against the timesaving benefits it would entail. For timestamp checking there are roughly 700 Danger Report pages that would benefit. And 81 pages of the SIM. And 100 pages of the NT Status Map. The Mobile Phone Mast and List of Revivification Points are two pages that could also benefit from timestamp checking. The fact that 900 pages can't be maintained automatically for something as trivial as being unable to check the age of the last update is pretty poor in my eyes. Nevermind the other benefits, just automating processes for marking data as 'old' or statuses as 'unknown' would save much time. --  RoosterDragon  18:03, 17 May 2008 (BST)

They can be. Write a bot. Or download one. There's a whole slew of bot functionality built into the wiki software.--Jorm 21:56, 17 May 2008 (BST)

Currently scraping the edit page and making a http post submission based on the data from the edit form is the only way to perform edits. That's hardly whole slew. Plus, bot programming is outside many peoples technical or practical grasp, as it requires knowing a lot of non-wiki related tasks, such as (potentially) site adminstration (for PHP bots) etc.  Swiers 01:01, 18 May 2008 (BST)

There if you need it, no drawback if you don't

This seems a no brainer to me. If this stuff doesn't make sense (and seem useful) to you, you don't need to worry about it. Everything you do would still work just as before. But for people who can use it (Morgan, and myself) it could save hours of editing work each month on exiting projects, never mind the fact that new projects could be implemented much faster and be more efficient out of the gate.
So yeah, for some people (Morgan, Karek, the Roster, myself, maybe a few others) this could be a huge help. To the rest, it has no drawback.  Swiers 20:17, 17 May 2008 (BST)

Rabble Rabble Rabble! I fear change! Four more with Clinton and Gore! ..... ok, im done now. --Bullgod 20:36, 17 May 2008 (BST)

Pretty much that. It would be great for keeping things updated with less work- always good, and I can't see any major drawbacks. --BoboTalkClown 23:45, 17 May 2008 (BST)

Really, only the people who build (or improve) systems that function through complex templates and multiple page transclusions are ever likely to dabble with parser functions. In fact, most of those systems are already using templates that attempt to recreate a portion of that functionality. Most regular contributors will never have need of them, and need never even need to think of them, just as they currently have no need to ponder templates such as Ifdef (used on over 2000 pages), even if they regularly edit pages that make use of them. --Morgan Blair 08:37, 18 May 2008 (BST)

Please weigh in with your final opinion

Since nobody's had anything to add to the discussion in the past couple of days, I've added a section for signatures on the project page. If you care to, please add your signature there in support of the appropriate position (regardless of having had anything to say on this page).
To those who've contributed to the this open discussion over the past few days, thanks for taking the time to share your views, and also for keeping it (generally) civil. While it amuses me to no end how people (including myself) can begin to be heated over a subject as seemingly bland as a MediaWiki extension, I appreciate when folk are able to carry out their arguments over diametrically opposed viewpoints in at least a semi-reasonable tone.--Morgan Blair 01:18, 23 May 2008 (BST)

Since when did "open discussions" become "voting platforms?"--Jorm 01:39, 23 May 2008 (BST)

It's just organizing comments... --  AHLGTG THE END IS NIGH! 01:43, 23 May 2008 (BST)

The signatures are simply indicating individuals' resulting opinion on the subject, now that the discussion has run its course. Though I had stated on the project page when I first introduced the subject that, after discussion took place on this page, ". . . any points of consensus for or against can be summarized [on the project page].", I failed to establish the criteria by which any consensus would be determined. Thus, it seemed appropriate to ask for it on the subject as a whole; that I have done so now should by no means be construed as an attempt to create a "voting platform". While you might have validly expressed criticism of my original intent to obtain consensus in the forum of an "Open Discussion", your skepticism at this point hardly seems appropriate. --Morgan Blair 02:21, 23 May 2008 (BST) p.s. Jorm, I should be more appreciative of the point: "Full of piss and vinegar." Please forgive me if my disapprobation appears severe.