On 12 March 2012 15:49, Hydriz Wikipedia <admin(a)alphacorp.tk> wrote: Could we (in general) *please* not do this? If someones tools are important enough to be taken over by someone else, they are most certainly important enough for a multi-maintainer project. In {one month, one year, five years}, Tparis' account will also expire and we will have the same problem all over again. Best, Merlijn _______________________________________________ Toolserver-l mailing list (Toolserver-l(a)lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette

Maybe there should be a path for converting an inactive user into a MMP,

On 12 March 2012 15:49, Hydriz Wikipedia <admin(a)alphacorp.tk> wrote: Could we (in general) *please* not do this? If someones tools are important enough to be taken over by someone else, they are most certainly important enough for a multi-maintainer project. In {one month, one year, five years}, Tparis' account will also expire and we will have the same problem all over again. Best, Merlijn

On Mon, Mar 12, 2012 at 5:54 PM, Soxred93 wrote: If you are pushing for an MMP, it would be best not to use my code. It's shoddy, poorly written, broken, and inefficient. Frankly, I'm amazed it lasted as long as it did. -X! Well, it's been working so far. I'd recommend we do the following: * creating a few MMP projects that cover the tools people use most * make your home directory readable for group 'users' via chmod (except for sensitive files) * watch and see people copy your stuff into the SVN repo for the MMP projects and check them out into the MMP account, and see people open stuff in JIRA and get fixed in svn and pushed live :) -- Krinkle

Platonides <platonides(a)gmail.com> wrote: I had similar thoughts recently when faced for the n-th time with accessing Wikipedia per MySQL (on the toolserver) or the API (elsewhere) in Perl. It would be nice to have one module with an interface that can be used by Toolserver users and others as well. Skins fall into this category as well: I think most developers could easily adapt their tools to use a centralized skin, but wouldn't bother to implement one by themselves that is accessible and usable.

Even if only for PHP there would be a critical mass, it'd be still useful to Perl, Python and other developers. For example, I think it is a common problem to normalize links - e. g., are "[[Diskussion:ABC_abc#.C3.A4.C3.B6.C3.BC]]" and "[[de:Talk:aBC abc#äöü]]" pointing at the same resource? Most developers start with the easy bits and end up with something that works for most of their use cases, but fails if that line is overstepped (for example "Image:" -> "File:"). If there was an existing module for this, you wouldn't have to think about all the fringe cases yourself, but could base upon the sweat poured by others :-). If Me- diaWiki got updated, you would just have to look at the changes in the PHP module and port them to your language of choice.

[...] At the risk of over-designing, would it be worth to gather language-independent requirements for a module/library, on the toolserver wiki or on meta, and then keep implementations of that standard (yes, I know, "one more standard") available on the toolserver? At the very least, a language-neutral brainstorming might prevent design flaws, especially with database-with-API-fallback in mind.

Magnus Manske wrote: It depends on what you mean by "requirement". Something like "a library *must* provide a function normalizeLink() with these semantics" would probably deter developers from trying to implement it. If on the other hand there was an algorithm "if you want to normalize links, do A, B, C, D and E" and corresponding test cases to check compliance, I think it would be much more inviting. Tim

On Thu, Mar 15, 2012 at 8:33 PM, Tim Landscheidt <tim(a)tim-landscheidt.de> wrote: +1. Speaking as a framework developer, build a test case and it shall be done! If the list will allow a shameless self plug, based on this thread I've developed an alpha version of a framework (PHP-only, sorry) that: a.) supports all actions and queries in the API without any specialized code in the framework b.) supports updates to the API with a simple svn update, and c.) automagically selects a backend (HTTP by default but database server if available) for queries without the need to code for any given environment. Right now I'm seeing speed increases on the order of 2.5x and am a very happy camper. I've got to make it look all pretty (phpDocumented and such) and fix a couple encapsulation violations in the architecture, but if anyone's interested in betaing it once I can stand others looking at it, let me know! It's possible some bugs aren't going to be found except through actual use cases, encountering things like columns and indexes that don't exist on the Toolserver. Cheers, -Madman

On Sun, Mar 18, 2012 at 10:10 PM, Sumana Harihareswara <sumanah(a)wikimedia.org> wrote: Haha, no worries. As it happens, I've made enough progress that I anticipate releasing documentation and examples by the end of tomorrow (today?) and the base code by the end of the next day. I don't mean to be a tease, so to speak. :P Unfortunately, my OCD makes me apply absurdly arbitrary and exacting standards to any code when it has my name on it. This also makes it difficult for me to use source control (though I *do*, as it's absolutely essential to development) as I don't like keeping around code that didn't work or code that's no longer needed; it doesn't seem "organized" to me. I'm not familiar with Git, but I'll look into it; as the framework has a dependency on MediaWiki, it'll probably be best to use what MediaWiki's going to use, especially if I can define it as an external repository. That way I wouldn't have to keep metadata around that might not be able to be checked in, write a checkout script, or have the possibility of having an old version of MediaWiki distributed with the framework. Thanks! -Madman

Unfortunately, my OCD makes me apply absurdly arbitrary and exacting standards to any code when it has my name on it. This also makes it difficult for me to use source control (though I *do*, as it's absolutely essential to development) as I don't like keeping around code that didn't work or code that's no longer needed; it doesn't seem "organized" to me. I'm not familiar with Git, (...)