Guild Wars Wiki talk:Requests for technical administration/Archive 3

Guild Wars Wiki:Requests for technical administration/Cite or Cite.php

It looks like everyone forgot about this one. I've also proposed it on the other wiki at Guild Wars 2 Wiki talk:Requests for technical administration#cite.php. -- Gordon Ecker 00:24, 31 July 2008 (UTC)

Actually I don't see a need for that; nearly everything on the wiki is from in-game, so citations - or rather the references - aren't really needed. poke | talk 12:28, 31 July 2008 (UTC)

I could see it being useful for lore articles (for example, referencing the manuals, interviews, magazine articles, etc.). Might even be used as Gordon describes on the request's talk page. It won't hinder other articles, but it will be useful for others. -- Brains12 \ talk 14:37, 31 July 2008 (UTC)

I have to agree with Poke. There are only a handful of practical applications for this, all of which work perfectly fine at the moment. Calor 15:44, 31 July 2008 (UTC)

I agree with Brains, but isn't there a little symbol that we already use to site things like manual text and official lore? --People of Antioch 13:56, 17 August 2008 (UTC)

That's only for entire pages, not for the citation of specific details. -- Brains12 \ talk 19:00, 17 August 2008 (UTC)

Category tree extension

I have recently been looking at the Category structure here on GWW, and I am convinced that getting the Category tree extension would be of benefit to us. It would give us a tool to be able to easily see where categories are being added as well as to see where categories may be needed for better organization of the information.-- Wyn 16:54, 15 August 2008 (UTC)

Is this the one that gives the "+" symbol on category pages in wikipedia? If so, then no objection from me. -- ab.er.rant 15:09, 17 August 2008 (UTC)

same here. poke | talk 15:12, 17 August 2008 (UTC)

Thirded. Calor 17:32, 17 August 2008 (UTC)

I think this extension adds that "+" symbol to all categories, even ones that do not have one. It would just pop up the text: "No subcategories". I would like it *better* if that was left out or fixed somehow. --People of Antioch 17:54, 17 August 2008 (UTC)

Extension to prevent page names from containing certain text strings

Is there an extension allowing specific text strings to be banned from page names? Spambots ofter create pages with names ending in /index.php, and some characters such as \ and ~ cause problems when used in page names. -- Gordon Ecker 06:23, 18 August 2008 (UTC)

Extension:Title Blacklist would do it. ¬ Wizårdbõÿ777(talk) 17:24, 18 August 2008 (UTC)

I'll go create a request page for it? Calor 17:26, 18 August 2008 (UTC)

I disagree; where is the problem with what sort of pages? It is much better to simply adjust the modrewrite settings. poke | talk 17:39, 18 August 2008 (UTC)

Pages like User:~nymph~ are hard to access? And what are these modrewrite settings you speak of? ¬ Wizårdbõÿ777(talk) 17:43, 18 August 2008 (UTC)

So you basically want to disallow that user from creating a userpage.

http://wiki.guildwars.com/index.php?title=User:~nymph~ works; as I said, it's a problem with the url-rewrite. And mod_rewrite is a server module that allows to internally rewrite urls to others without having the user notify it. Basically everthing on the wiki beginning with /wiki/ is rewritten. poke | talk 17:46, 18 August 2008 (UTC)

If URL-rewrite can deal with problematic characters, it would be a better solution for them. However I still think we should blacklist any page name containing /index.php, since it's a common target for spambots and that text string has no reason to exist in the names of legitimate pages on this wiki. -- Gordon Ecker 02:06, 19 August 2008 (UTC)

AllowImageMoving and DeletedContributions

Manual:$wgAllowImageMoving can be used to move images, making it easier to follow our image naming rules and for general maintenance. Extension:DeletedContributions allows sysops to view editors' deleted contributions, something useful in cases of a returning vandal and the like. -- Brains12 \ talk 23:57, 23 August 2008 (UTC)

Agreed with the DeletedContributions extension; it is very helpful when checking vandals before blocking.

For the image moving, it is not that easy as it looks like. The setting was introduced in MW 1.13, so it is not available for us yet, and as it states on the page, it is not really a safe function. As a solution, we could set up a template that requests image moves, and I could have Wikichu periodically move those images. poke | talk 00:08, 24 August 2008 (UTC)

The suggestion for the AllowImageMoving was for when ArenaNet update to 1.13, or so they can test how stable it is on their testing servers. I know it says it's experimental, but we could ask ArenaNet to test how effective it is (seeing as they're testing 1.13 at the moment). You've been mentioning the image move requests and Wikichu moving images for a while now as a solution, but it's not actually being done or discussed :P. -- Brains12 \ talk 00:13, 24 August 2008 (UTC)

Oh, didn't saw that entry (why is Emily's journal always unwatched!?) - I know I have mentioned the Wikichu auto-moving some time ago, but actually it seemed as if nobody was really interested in it, apart from a few cases.. poke | talk 00:35, 24 August 2008 (UTC)

Ah right. Well, I'd rather have an independent way of moving images, rather than having to depend on one person and his bot (in case you go inactive or something). Passing that along so ArenaNet can test it would be useful, in my opinion -- if it doesn't work out (or ArenaNet refuse), then we can go for Wikichu. -- Brains12 \ talk 00:39, 24 August 2008 (UTC)

Definitely DeletedContributions. As for AllowImageMoving, I'd also support (no obvious pitfalls), unless, as Poke says, there are certain hitches. In which case, Poke/Wikichu can do it. Calor 00:43, 24 August 2008 (UTC)

So there is an extension for viewing deleted contribs, that's something I've been meaning to ask about for a while but never actually did, but anyway I'd support it. At this time I won't comment on the image moving one as I don't have the time tonight to check it out. --Kakarot 03:49, 24 August 2008 (UTC)

"(in case you go inactive or something)" <- loled on that :P But sure, if the MediaWiki image moving works correctly, it is easier than "copying" images to another place and "deleting" (=hiding) the old one. poke | talk 14:39, 24 August 2008 (UTC)

Deleted contributions would be a good addition. Image moving would be lovely, and it would be a good idea if it could be tested by Anet before the upgrade. As is says experimental, we really need to know if it will cause security problems or big hiccups. Just failing to move once in a while isn't that much of a problem. - anja 16:04, 24 August 2008 (UTC)

Depending on how it fails. If the images get completely lost, it would be a problem imo. poke | talk 16:57, 24 August 2008 (UTC)

That was my point. :P - anja 17:11, 24 August 2008 (UTC)

I concur on both parts with Anja. I've wanted deleted contributions for awhile now, just never got around to bringing it up here. And image moving, if it works, would be a great addition to save everyone headaches when someone uploads an image under a poor name. If all it is is something like occasionally the wiki'll throw an error saying you can't do that, that's not a big deal, it's still better than what we've got now. If it's something like crashing the wiki, images lost, etc, well, that's bad, hence why we'd like to have IT test it out while they're testing 1.13, and enable it if it's viable. - Tanetris 17:35, 24 August 2008 (UTC)

Yep. Being able to move images helps, especially since (if?) it keeps the upload log. -- ab.er.rant 13:13, 25 August 2008 (UTC)

DeletedContributions is available as default in MediaWiki 1.14. I think Emily said they were pondering missing out the 1.13 update and going straight to 1.14 when it's released. Even if this won't be the case, I'm sure it'd be a hassle for them to install it and then remove it when they upgrade to 1.14 (which I'm sure they will do soon after its release). Should we take this off the list? -- Brains12 \ talk 16:07, 7 October 2008 (UTC)

Bumpity. -- Brains12 \ talk 16:04, 10 October 2008 (UTC)

Oh! I forgot to agree! ;) poke | talk 16:08, 10 October 2008 (UTC)

Stick it as a possible pitfall and let them decide what they want to do? - Tanetris 17:56, 10 October 2008 (UTC)

Rating extansions

Which rating extension would be most appropriate for skill feedback entries? -- Gordon Ecker 02:43, 29 September 2008 (UTC)

http://www.mediawiki.org/wiki/Extension:Rating or http://www.mediawiki.org/wiki/Extension:Poll --Shadowphoenix 02:48, 29 September 2008 (UTC)

The rating extension would be a bit easier to use I suppose. --Shadowphoenix 02:49, 29 September 2008 (UTC)

IMO, none. We still haven't decided if we're going to use voting at all; and if we were going to use voting, we still would have to decide if we would use a rating system or not, and after that had been decided, we would still have to think if we would actually install a rating extension. I think it's too soon to be deciding which extension to install. Erasculio 03:21, 29 September 2008 (UTC)

I started this discussion here because the viability of systems which involve voting is related to the quality of available voting extensions, but I didn't want it to clutter Guild Wars Wiki talk:Community portal. -- Gordon Ecker 04:05, 29 September 2008 (UTC)

It should be pointed out that the Rating extension mentioned above is currently marked as experimental while the Poll extension is stable; that might be something to consider. (Aiiane - talk - contribs) 05:16, 29 September 2008 (UTC)

There's also AjaxRatingScript and JSKitRating. -- Gordon Ecker 06:07, 29 September 2008 (UTC)

I know that the polls on guildwiki have been having a number of problems (people not being able to vote, having to refresh/clear cache multiple times before vote shows up), so I don't know how stable that poll extension really is. Also, anyone could wipe all the votes simply by editing the poll, so that probably wouldn't be a great choice. ¬ Wizårdbõÿ777(talk) 06:30, 29 September 2008 (UTC)

I'm not familiar with any of the polling extensions. If a polling extension is compatible with transclusion then the poll itself could be on a protected, transcluded subpage, preventing polls from being wiped. -- Gordon Ecker 07:11, 29 September 2008 (UTC)

AjaxRatingScript seems to have the functions we would need and is used by several other wikis (as linked from the mediawiki page). --Xeeron 10:06, 29 September 2008 (UTC)

Why would we want something like that? It causes problems but provides no useful sevice? Backsword 11:27, 29 September 2008 (UTC)

Another downside to the poll extension is that it doesn't say who has voted, meaning even more of a chance for proxy votes to go unnoticed. -- Brains12 \ talk 11:36, 29 September 2008 (UTC)

Please add WIKI extension:LoopFunctions.

→ moved from Guild Wars Wiki:Admin noticeboard

These are useful when you want to do a list of similar parameters. In particular #foreach can be used to process enumerated parameters, like the positional parameters. Also, if I understand/remember the documentation correctly, #for can be used for a list of other things that can be treated almost the same way, like a list of heros. —The preceding unsigned comment was added by Mtew (talk • contribs) at 18:42, 6 December 2008 (UTC).

I had thought about such a parser extension when I was setting up the Skill progression template, but solved it then without it. I can't imagine any other thing where it would be useful; as for lists we use DPL as that allows us to receive the information we want to display as well. poke | talk 19:04, 6 December 2008 (UTC)

Two things: First – Where is the documentation on DPL?  Second – Almost any problem can be worked around.  The difficulty arises when the time comes to change something.  For example, if there is a pattern to the parameter names used, adding a new instance to the pattern seems to be simple (if not trivial) with the LoopFunctions.  In particular, I am trying to work up a template that takes a variable number of positional parameters.  My current implementation can handle up to nine positional parameters; there are eight copies of a section of coding that checks to see if the parameter is present and then invokes another template to handle the instance if it is.  It is OK as it stands, but there are two fairly minor problems: 1 – If someone needs more positional parameters, the template has to be edited to handle the extra parameters, and 2 – The check for each additional parameter has to be done each time the template is invoked and each check requires additional storage for the checking code.  This puts a minor but unnecessary load on the server.  Having the LoopFunctions extension available would simplify the code which would save storage space, slightly reduce the load on the server, and make the template easier to maintain. 

Also, the problem you had seems to be a fairly simple table construction problem; a problem that should have a fairly standard solution using a data base of one form or another.  The problem this stuff is intended to handle is repeated chunks of code.  mtew 12:00, 7 December 2008 (UTC)

http://semeb.com/dpldemo/index.php?title=Dynamic_Page_List has a manual, FAQ, examples, etc etc. - Tanetris 15:28, 7 December 2008 (UTC)

Good link. Thanks. It is good for collecting data and only indirectly useful for code maintenance AFAICT. mtew 16:23, 7 December 2008 (UTC)

This puts a minor but unnecessary load on the server. You do realise the ironic element here? Given that storing a few lines of text is an extremely minor load compared to running a full extension... Backsword 07:38, 9 December 2008 (UTC)

1) The extension is only run when it is called for.  2) It might save hundreds of lines of storage.  I would have to go through all the templates to get a good number.  3) It would save having to interpret many hundreds of lines of WIKI code.      Mtew 12:57, 13 December 2008 (UTC).

Uhm no, if you believe that, you don't understand how extensions work on MediaWiki. They are run always as they all check the code on their own. It is not possible to have check the code once and then only call those extensions which actually do something with the code. Also I extremely doubt that we could save "hundreds of lines" by using that extension; we simply do not have enough things where something like that would be useful. Interpreting normal wiki code is actually quite easy, especially as the results will be cached, that is not an issue. Additionally the LoopFunctions extension still returns wiki code (as DPL does) which needs to be interpreted, so that argument is bad... poke | talk 16:54, 13 December 2008 (UTC)

If I understand you correctly, that would mean each extension is called in turn (when an '#' is seen?) and that extension checks for its own function names.  If it finds one, it dispatches to the code that implements the function and returns with some sort of done indicator and the WIKI rescans the edited code.  If the extension does not find a function it implements, it returns a not done indicator and the WIKI calls more extensions until one of them returns a done indicator.  If that is how it is implemented, the order in which the extensions is called would have an impact on performance; the more frequently used extensions should be called first.  I had expected that each extension would add its function names, and pointers to the corresponding implementation code, into a hash table on extension initialization.  That would cause each extension to only be called when invoked, but you imply it is done the other way. 

As for the number of lines saved, the Collapsible list template would need one or two lines where it currently has fifty, and if there are other similar templates, the line count could easily exceed a hundred.  However, you are more familiar with the template code than I currently am, which is why I used 'might' rather than making a flat assertion.  If, as you said below, the Collapsible list template is never used, then deleting it, as I suggested there, would still save storage space.  But with the current price of disk storage, I completely agree with you about the cost of storage being a non-issue. 

As for the WIKI code generated, only the code for the matching parameters would be generated, not the unnecessary ones, which would be a clear reduction in the amount of WIKI code that would be needed to be parsed.      mtew 18:33, 13 December 2008 (UTC)

No, not exactly like that. Whenever the parser is run, it registers all installed extensions by calling the initialization function, the extension provides. This function registers the hooks (here: function hooks starting with #). Now when the MediaWiki parser looks for hooks, it looks the hook name up in a table which extension registered it and calls the extension function to do something with the parser-function's content. The extension then does something with it and returns it; after that the returned code still has to be checked again, so the parser can be sure that there were no other hooks in the generated code.

By this each extension does not have to look through the complete code, but there is still additional load even if the appropriate parser function was not used.

But don't misunderstand me, I don't want to use that as an argument against the extension, it is still just, that I don't see any need for it on GWW. poke | talk 22:40, 13 December 2008 (UTC)

Ah!  Communication mismatch.  If you think about what you just said, you should see that the mechanism you just described is equivalent to the method I had thought was being used with names for the different pieces changed.  Note that the initialization function is called once when the server is started, which can really be ignored because the load it generates does not recur for each WIKI code token.  The load that the extension places on the system during operation is only the code needed to implement processing an action token; it does not occur if the #function is not used.  So, if I understand you correctly, no additional load is added by installing an extension until the extension is called for by WIKI code.  That is installing an extension would not add to the load generated by any other action token.  (I am ignoring possible hash table collisions I'll admit.  I expect that you will agree that, if they occur at all, they are truly trivial.) 

But, if what I just said is true, your next paragraph does not logically follow unless you consider just sitting in memory as a significant addition to the 'load'.  (It could be you were making a pun, since each extension is 'loaded', but that isn't what is usually meant by the term 'load'.  It usually refers to the running load; the amount of time used to run the code.) 

However all that is beside the point because you said you are looking for ways the extension could improve this WIKI.  Sub-thread end?  The hunt for uses is being argued in another sub-thread.      mtew 05:09, 14 December 2008 (UTC)

I am curious where on Guild Wars Wiki specifically this would be beneficial. If it is only for use in creating complicated user pages, I don't see the benefit. Can you please give an example of where in the mainspace this would be useful? -- Wyn 18:50, 7 December 2008 (UTC)

<hummor> Actually it would encourage splitting user pages, making them simpler.</humor>  The userspace pages provide a test bed for future mainspace pages, so the initial uses will mainly be on user pages, but, as their use becomes known, they will find other applications.  I redid the Tabs template precisely because I wanted them for a quest summary tree I am writing. 

Frankly, I have not looked at enough of the coding of the main pages to say where this would be useful by itself, but having a quick way to understand and switch within the page hierarchy could make things easier to find.  While the Categories box helps a lot, other navigation aids would be useful.  As a guess, any template box with lots of parameters has a potential for using these.  The PERL motto 'there is more than one way to do it' applies. mtew 23:37, 7 December 2008 (UTC)

I still fail to see any real use.. Can you give some real example of what is possible and where it would help? poke | talk 08:14, 8 December 2008 (UTC)

The template 'NPC infobox' has some sections where '#foreach' could be used to shorten the code and remove the arbitrary limit on the number of instances of a particular parameter.  There are probably several others that can be dug up.  mtew 14:13, 8 December 2008 (UTC)

I looked at that template code and I couldn't really see what you were getting at. It looks pretty straightforward to me; just check for each parameter and put the corresponding info into it. --JonTheMon 15:17, 8 December 2008 (UTC)

And not having the tool, you don't know how it can be used.  Chicken and Egg problem.  There is a series of enumerated parameters like 'mapN' and 'professionN' where N can be a small number.  The current code checks for the presence of the parameter and does something with it if it is not blank.  #foreach can be set to loop over the parameters that exist and do the specified action for each of them.  The presence test would not be needed since #foreach does that check internally and any number (up to 100?) of parameters can be handled.  At least that's what I think the documentation says.  mtew 20:25, 8 December 2008 (UTC)

That is a good example of where it might be a good fit. More please? --JonTheMon 20:31, 8 December 2008 (UTC)

That's reasonable.  I'll see what I can do.  I've got some other things eating my time, so I won't be able to get the additional examples very quickly.  mtew 06:56, 9 December 2008 (UTC)

Template:Collapsible list mtew 12:47, 13 December 2008 (UTC)

One of the worst examples you could give. That template is neither used anywhere nor helpful at all. Plus it is copied from Wikipedia and wouldn't work here at all as we use a completely different way to display collapsible things. poke | talk 15:17, 13 December 2008 (UTC)

Hmm.  I should have checked the 'What links here' list, and didn't.  However, if what you say is true (and I do not doubt that it is) then that template should be deleted.  Still, it a valid example, even if a poor one.  I will continue to add examples when I find them;      mtew 16:32, 13 December 2008 (UTC)

poke's Skill progression template, as he mentioned earlier, could have used extension:LoopFunctions to some advantage.  That is one big chunk of repetitive code!  Neat trick with building cell columns.  I learned something new from it.  It gets just a little funky when it has to wrap the enumeration.      mtew 05:54, 15 December 2008 (UTC)

Template:Pagelist.      mtew 12:53, 19 December 2008 (UTC)

I've never been a big fan of solutions in search of a problem. If we installed every wiki extension that could possibly potentially be used for something, well, there are over 1,000 extensions listed on mediawiki.org, and all of them presumably have some sort of use. The example you give of the NPC infobox, certainly the extension can be used there, but I'm not sure I see the tangible benefit? The number of professions an NPC can have are limited to a small number by the way NPCs work (and the number of professions in existence, for that matter). As for maps, if we're using more than 5, at least some of those maps should probably be combined. I can't imagine many even use that many (Poke is crunching those numbers with his bot magic, but I'll just have him post when it's done running, which will apparently be tomorrow since he's going to bed Apparently there are 10, compared to 1,707 pages with 1 map). So I don't see what this adds to the functionality of the NPC infobox; the only benefit seems to be that the code will be shorter? Considering templates only need to be set up once and 99% of wiki editors will never even look at the infobox's code, this seems a scant benefit.

If what you want is to find out with this extension can do to see if it would be useful to the wiki, I'd suggest finding some other wiki that does have it installed, or make your own testwiki, and play around with it there. Any extension carries that much more risk of something interacting poorly and breaking, not to mention the time the IT guys have to take to install and test it, and I don't think just the possibility that we'll find something useful to do with it outweighs that. - Tanetris 22:31, 8 December 2008 (UTC)

So you're not a fan.  Neither am I.  I am not suggesting that "every wiki extension that could possibly potentially be used for something" be installed, and you are being intellectually dishonest in suggesting that I am doing so.  I was asked for an example of how the LoopFunctions could be used in MainSpace and took some time to find one. 

Further, your statistics actually show that using the LoopFunctions would be very beneficial.  Only 10 instances out of 2000? need the fifth test in the current version.  As a guess, LoopFunctions would remove half, or maybe three quarters, of the code needed to handle all the extra maps.  The same is true with professions.  That would produce a minor performance improvement every time the template is invoked.  By comparison, the reading activity of the editors is inconsequential. 

I do have other things to do and digging through WIKI that do not contribute to my projects is not a reasonable request.  I was thinking of setting up a test WIKI of my own, but it is not something to be done on the spur of the moment.  As for the IT guys, they will know the risks involved better than either of us.  I am making a request, not stating a requirement.  I am more than willing to leave the decision in their capable hands.  Which brings up the question – Why the hostility? mtew 06:56, 9 December 2008 (UTC)

Nobody's being hostile. However, if you agree with Tanetris that this is a solution lacking a problem, why are you suggesting it at all? Why are you requesting something that solves nothing? - Auron 07:50, 9 December 2008 (UTC)

I consider putting words in my mouth that I neither said nor implied to be somewhat less than friendly.  I also disagree that this is a solution looking for a problem.  While the problem is a small one at present it is still a real problem.  mtew 13:02, 9 December 2008 (UTC)

Technical note on NPCs: they only have primary professions, but have independent skill bars and can thus have up to 8 'secondaries'. Backsword 07:40, 9 December 2008 (UTC)

Maybe so, but that is the name of the repeated parameter.  mtew 13:02, 9 December 2008 (UTC)

"Only 10 instances out of 2000? need the fifth test in the current version. As a guess, LoopFunctions would remove half, or maybe three quarters, of the code needed to handle all the extra maps." out of ~5000 to begin with; In code it may look as if there are tests removed; however those loop functions test if the parameter is set internally, so there is no check saved (probably it would be getting worse, as loop functions allow a much higher number of parameters). Apart from that the current code for one map is one line. For a normal code editor it is quite obvious what happens there and what would be needed to increase the number of maps. With a complicated loop code that, to keep it a bit more clear, would go over 3 lines. We would save 2 lines - yay! - but have a complicated code for 24 maps at all.

Sorry, but if you don't have a better argument for installing that extension I oppose. poke | talk 08:00, 9 December 2008 (UTC)

OK, 2000 was a guess on my part.  If there are something like 5K invocations, that is 2.5 times worse.  The amount of apparent code is important.  IIUC the WIKI code is interpreted and puts more load on the server than .php code.  That would make a test at the .php level less expensive than a test at the WIKI level.  I have not looked at the .php code but from the description the loop is over the number of parameters to the template, checking to see if their name matches the pattern.  It is very unlikely that it explicitly tests for 'map100', but I could be wrong.  Further, using the LoopFunctions would make the code simpler and easier to maintain, at least in my opinion.  It would make no real difference to the average users of the template.  While I can speak only for myself, fixing a typo in a loop seems much simpler than fixing the same typo in five (or whatever) lines.  mtew 13:02, 9 December 2008 (UTC)

Again mtew, we are not being hostile, but the request won't even be forwarded to the IT guys if the community doesn't agree it's a necessary addition. That's why the questions etc. If there were a proven place where this would solve an ongoing problem, or make the documentation of the game and organization of that documentation easier/better, it would meet with a better community response. -- Wyn 10:01, 9 December 2008 (UTC)

Hostile - see my response to Auron. 

I like answering real questions.  What I don't like is delousing emotional arguments.  I will explain why I think an argument has a misconception in it.  I just hope that people will try to understand my point of view.  I try quite hard to see the point of view of others. 

I consider having an arbitrary limit on the enumeration of some parameter complicated.  It means that I have to know and remember that limit.  IMO, having a large limit and a simple pattern in the implementing code is better; it requires less maintenance.  The observation that "there is no time to do it right, but always time to do it over" really rubs me the wrong way.  mtew 13:02, 9 December 2008 (UTC)

I apologize if my response came across as hostile; I was aiming for skeptical. I also did not mean to suggest you wanted us to install all those extensions, rather I was trying to explain the larger principle behind being picky about reasons for this particular extension.

I confess I am not sufficiently technical to be certain of the performance differences between what we have now and the proposed LoopFunctions, but I do trust Poke's technical knowledge, and he seems unconvinced. If you can convince him that there would be significant performance benefits, consider my opposition dropped.

As for why I'm opposing in the first place when it's "just a request", requests that are passed to IT are considered to have the backing of the whole community, and IT considers them with that in mind. An official request means not just that you're asking, but that Poke's asking, Wyn's asking, Auron's asking, I'm asking, etc etc, and I'm not comfortable asking them for something without a more substantial reason. - Tanetris 15:41, 9 December 2008 (UTC)

OK.  Slippery slope arguments like that make some sense but can also be an excuse for doing nothing.  The difference between not supporting a request and opposing it is also significant. 

The performance difference is very likely to be fairly minor.  The main impact is removing arbitrary limits that can bite unexpectedly.  Admittedly that is more of a philosophical point than a technical one.  I also think the argument he made about risks to be marginal at best.  If a problem like that were to show up, it should be reported to the developers of the troublesome code;  Using that potential as the basis for opposition is a bit extreme; I can see it as a reservation in the form 'if this causes significant trouble, we can do without it' as part of the request to IT.  mtew 17:00, 9 December 2008 (UTC)

(Reset indent) How I see it right now is like getting a new set of tools or doing a new construction job. If it's built already, do you want to rebuild it with the new tools? And if you only use that tool once, is it worth it to buy it? So we're looking for more areas with a more pressing needed. --JonTheMon 17:15, 9 December 2008 (UTC)

If there is a problem that has you mucking around with something anyway, using the new tool to clean up would make sense.  If you want to test the tool or learn how to use it, rebuilding something that 'sort of works' is also reasonable.  If you really have nothing else to do and are willing to assure that the reconstruction does not cause problems, well maybe.  Ask first. 

I was under the impression this was FOSS. If it isn't, I withdraw my request! 

I said I'd look for other places it could be used, but I am not going the drop everything else to do so.  I'd be surprised if this was put in tomorrow.  I'd still be surprised if the was put in next week.  After Christmas when thing have calmed down a little is more like it.  Waiting for spring to ask IT would disturb me.  mtew 18:20, 9 December 2008 (UTC)

LOL! You are optimistic aren't you? Another consideration is whether or not this extension will be affected by v 1.14, there are 3 requests for extension additions that have been in place for months now, but are on hold waiting to upgrade to v 1.14. So if by After Christmas you mean Easter, you are more likely on track :D -- Wyn 18:36, 9 December 2008 (UTC)

Well that is bit disappointing, but if that's the way it is, that's the way it is.  I should be able to dig up the examples needed by then.  I might even get my wiki tester up by then.  mtew 21:47, 9 December 2008 (UTC)

Could you please stop looking for examples and especially adding text in between of this long discussion? I think it is quite obvious that this proposal for that extension is not supported by the community, so please just forget about it until there is a real need. The examples you have given work as they are with no problems and they are never even looked at because they just work - so there is just no need to "clean" code up or to save space. poke | talk 12:59, 19 December 2008 (UTC)

Do not fix that which is not broken. The benefits of this extension does not outweight the practical issues though. Sure, it might be easier to maintain a few selective templates, but you have to keep in mind that the mainenance need is only moved from templates to the wiki core. Updating, debugging, etc. Someone still has to take care of that. — Galil 19:42, 19 December 2008 (UTC)

User:poke: Wilco.  There was a specific request for more examples of where this extension could be useful.  I was not saying that the examples should be fixed.  If added at the end, they would seem out of context.  I was putting them in their context.  Presumably, there are enough now. 

User:Galil: Fixing things that are not broken is not the intent.  (Discussed earlier.)  Making it possible to write new things without unneeded restrictions and clutter is. 

While someone does have to maintain the extension, it is not Arenanet, nor is it NCSoft.  In fact, both of them would be doing the larger community a disservice if they tried.  The correct people to do the maintenance are the people who wrote and maintain the extension.      mtew 18:58, 20 December 2008 (UTC)

Eh? The thing is that only ANet can install/update/whatever things on the wiki server; so ANet is involved in everything that changes anything on the server.

"Making it possible to write new things without unneeded restrictions and clutter is." - you still didn't tell us what exactly you imagine that would be possible to be added with that extension. poke | talk 13:29, 21 December 2008 (UTC)

Install and update, absolutely.  Debug and Maintain (a.k.a. whatever), only as little as can not be turned over to the suppliers. 

Application: reasonable point.  The stuff I am working on that could use this is mostly still in very crude states because I am still learning what to do.  While it is intended to eventually be useful in the main space, I will admit that it is not at this point.  The situation is sort of like wanting to use screws in a project and discovering that the only tool in the tool chest is a hammer.  I have generally received a 'we don't need that' response when I open my mouth.  I do not find that particularly encouraging.  Admittedly the ideas are half baked, but I have been careful to NOT break things.      mtew 18:45, 21 December 2008 (UTC)

You keep telling us you want this different tool, and that it will let you (and us) do different things, but you've presented no evidence that that's actually true. To extend your analogy, all your examples have been are places where nails are holding something together perfectly well. Sure, screws could hold it together too, and maybe we'd need a few less screws than nails, but the nails aren't going to fail and the screws won't make it a better whatever-we're-building-in-this-analogy.

If you told us something you cannot currently do without this extension, or something that would be significantly functionally better with this extension, that would go a long way toward convincing us. - Tanetris 21:11, 21 December 2008 (UTC)

If that is what you all are demanding, then I can not meet your demand.  A loop can always be unrolled so there is never going to be a case where something can not be done without the LoopFunctions.  By analogy, you are saying since we can get along without a screwdriver, there should not be one in the tool box.      mtew 00:17, 22 December 2008 (UTC) _{mutter mutter mutter}

Quoting Tanetris just one answer ago "...or something that would be significantly functionally better with this extension...". Using your same example, we can get along without a screwdriver, but if we need to screw screws, having a screwdriver makes life easier actually. Is there some screw in the wiki that can be screwed with loop functions?.--Fighterdoken 00:25, 22 December 2008 (UTC)

Dunno, I'll call the plumber. -- Brains12 \ talk 00:29, 22 December 2008 (UTC)

Fighterdoken: Yes.  That was the list that poke was complaining about.      mtew 00:38, 22 December 2008 (UTC)