We had a great discussion at the MediaWiki dev summit just now on service-oriented architecture and future plans in that direction... as always the community seems a bit split on the subject.
Breaking things out to separate services can indeed make setup and maintenance more complex... pro-services/pro-VM/pro-hosting folks like me tend to say "hey that can be automated!" (and MediaWiki-Vagrant shows a lot of awesomeness to start, though it's very developer-focused).
One thing that comes to mind though is something Gabriel mentioned about wanting stateless services for things like image manipulation and citation parsing and whatnot -- in principle many services like this could be opened up to public use.
For instance, a random MediaWiki instance could use a Wikimedia-hosted image scaler or graph rasterizer.
Usage limits and API keys could be introduced if we're worried about overloading.
Whether this can apply also to things like Parsoid might be tricky -- that's the biggest Scary Thing since core editing with VE/Flow is going to depend on it.
Anyway, just thoughts. :)
-- brion
On 27 January 2015 at 11:04, Brion Vibber bvibber@wikimedia.org wrote:
Whether this can apply also to things like Parsoid might be tricky -- that's the biggest Scary Thing since core editing with VE/Flow is going to depend on it.
Running Parsoid as a public service (with some soft-ish API limits) would allow us to support the oft-cited user who has a dumb PHP-only box and no means to install a node service, so that has my support; however, I worry that WMF might not be the best organisation to provide this if people wanted it at large for commercial use.
J.
On Tue, Jan 27, 2015 at 11:10 AM, James Forrester jforrester@wikimedia.org wrote:
On 27 January 2015 at 11:04, Brion Vibber bvibber@wikimedia.org wrote:
Whether this can apply also to things like Parsoid might be tricky -- that's the biggest Scary Thing since core editing with VE/Flow is going
to
depend on it.
Running Parsoid as a public service (with some soft-ish API limits) would allow us to support the oft-cited user who has a dumb PHP-only box and no means to install a node service, so that has my support;
Yay!
however, I worry that WMF might not be the best organisation to provide this if people wanted it at large for commercial use.
Agreed... but if not us, then who?
/me looks around at folks, wonders if anyone wants to commit to running such a service as a third-party that we could make super-easy for shared PHP-host users to use...
-- brion
On Tue, Jan 27, 2015 at 11:20 AM, Brion Vibber bvibber@wikimedia.org wrote:
Running Parsoid as a public service (with some soft-ish API limits)
would
allow us to support the oft-cited user who has a dumb PHP-only box and no means to install a node service, so that has my support;
Yay!
however, I worry that WMF might not be the best organisation to provide this if people wanted it at large for commercial use.
Agreed... but if not us, then who?
/me looks around at folks, wonders if anyone wants to commit to running such a service as a third-party that we could make super-easy for shared PHP-host users to use...
This is essentially the wordpress.com model for things like anti-spam and analytics, right? Not that I'm saying they would do it, but clearly it's a workable model at some scale.
Luis
We already run a public Parsoid service.
Kiwix uses it, as does Nell's Wikipedia. I believe some non-WMF content translation efforts also use it.
Usage limits and API keys would probably be a reasonable thing to do, longer-term. --scott
On Tue, Jan 27, 2015 at 11:20 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Tue, Jan 27, 2015 at 11:10 AM, James Forrester < jforrester@wikimedia.org> wrote:
On 27 January 2015 at 11:04, Brion Vibber bvibber@wikimedia.org wrote:
Whether this can apply also to things like Parsoid might be tricky -- that's the biggest Scary Thing since core editing with VE/Flow is going
to
depend on it.
Running Parsoid as a public service (with some soft-ish API limits)
would
allow us to support the oft-cited user who has a dumb PHP-only box and no means to install a node service, so that has my support;
Yay!
however, I worry that WMF might not be the best organisation to provide this if people wanted it at large for commercial use.
Agreed... but if not us, then who?
/me looks around at folks, wonders if anyone wants to commit to running such a service as a third-party that we could make super-easy for shared PHP-host users to use...
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 01/27/2015 11:46 AM, C. Scott Ananian wrote:
We already run a public Parsoid service.
But, this doesn't serve wiki content from wikis other than wikimedia wikis and we are unlikely to do so with the existing production WMF cluster.
The discussion is whether we should / will run a different cluster for smallish wikis.
Subbu.
Kiwix uses it, as does Nell's Wikipedia. I believe some non-WMF content translation efforts also use it.
Usage limits and API keys would probably be a reasonable thing to do, longer-term. --scott
On Tue, Jan 27, 2015 at 11:20 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Tue, Jan 27, 2015 at 11:10 AM, James Forrester < jforrester@wikimedia.org> wrote:
On 27 January 2015 at 11:04, Brion Vibber bvibber@wikimedia.org wrote:
Whether this can apply also to things like Parsoid might be tricky -- that's the biggest Scary Thing since core editing with VE/Flow is going
to
depend on it.
Running Parsoid as a public service (with some soft-ish API limits)
would
allow us to support the oft-cited user who has a dumb PHP-only box and no means to install a node service, so that has my support;
Yay!
however, I worry that WMF might not be the best organisation to provide this if people wanted it at large for commercial use.
Agreed... but if not us, then who?
/me looks around at folks, wonders if anyone wants to commit to running such a service as a third-party that we could make super-easy for shared PHP-host users to use...
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Another possibility is to shell out to nodejs-based services as an alternative to running them as ongoing web services.
This may not be super performant, but it should work -- just as we've been able to shell out to system binaries, Python scripts, ocaml, lua, etc for years. Would require having node *present* on the system but wouldn't require running a web service.
Something to consider trying...
-- brion
On Tue, Jan 27, 2015 at 11:20 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Tue, Jan 27, 2015 at 11:10 AM, James Forrester < jforrester@wikimedia.org> wrote:
On 27 January 2015 at 11:04, Brion Vibber bvibber@wikimedia.org wrote:
Whether this can apply also to things like Parsoid might be tricky -- that's the biggest Scary Thing since core editing with VE/Flow is going
to
depend on it.
Running Parsoid as a public service (with some soft-ish API limits) would allow us to support the oft-cited user who has a dumb PHP-only box and no means to install a node service, so that has my support;
Yay!
however, I worry that WMF might not be the best organisation to provide this if people wanted it at large for commercial use.
Agreed... but if not us, then who?
/me looks around at folks, wonders if anyone wants to commit to running such a service as a third-party that we could make super-easy for shared PHP-host users to use...
-- brion
On Tue, Jan 27, 2015 at 11:46 AM, Brion Vibber bvibber@wikimedia.org wrote:
Another possibility is to shell out to nodejs-based services as an alternative to running them as ongoing web services.
Parsoid currently does a lot of MediaWiki API querying at startup to get the current wiki settings. As a one-off service, this makes it rather sluggish. (We have a `parse.js` test binary that lets you experience this for yourself, if you like.)
I think it's more reasonable to embed v8 into PHP (or vice-versa) an an extension which lets us amortize this startup cost over a number of requests. --scott
On Tue, Jan 27, 2015 at 11:46 AM, Brion Vibber bvibber@wikimedia.org wrote:
Another possibility is to shell out to nodejs-based services as an alternative to running them as ongoing web services.
I have a hard time imagining a situation where you can install node and everything else, but would not just apt-get install parsoid https://www.mediawiki.org/wiki/Parsoid/Setup or mathoid. VMs that can run MediaWiki with all bells & whistles start at around $3 per month http://www.ovh.com/us/vps/vps-classic.xml these days, and are likely to become even cheaper.
I believe we can make installing a fully-featured MediaWiki service system as simple as copy&pasting 2-3 lines to a shell, or even executing a remote installer script that runs those lines for you. Additionally, we can offer VM images derived from the same install process through Bitnami or others.
To make this happen, we need to evaluate the options, make a decision and then follow through by making this our recommended and supported installation mechanism & providing a solid upgrade path for existing content.
I created https://phabricator.wikimedia.org/T87774 as a high-level tracking bug for the task of evaluating and deciding on a distribution strategy targeted at VMs.
Gabriel
On Wed, Jan 28, 2015 at 9:51 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
I believe we can make installing a fully-featured MediaWiki service system as simple as copy&pasting 2-3 lines to a shell, or even executing a remote installer script that runs those lines for you. Additionally, we can offer VM images derived from the same install process through Bitnami or others.
To make this happen, we need to evaluate the options, make a decision and then follow through by making this our recommended and supported installation mechanism & providing a solid upgrade path for existing content.
I created https://phabricator.wikimedia.org/T87774 as a high-level tracking bug for the task of evaluating and deciding on a distribution strategy targeted at VMs.
Excellent -- we should definitely work on making those available and get some folks to try em out and see how well that covers most needs.
-- brion
Gabriel and Wikimedia developers,
In what ways might you be anticipating developments with SemanticMediaWiki, and in what ways not?
Scott On Jan 28, 2015 9:52 AM, "Gabriel Wicke" gwicke@wikimedia.org wrote:
On Tue, Jan 27, 2015 at 11:46 AM, Brion Vibber bvibber@wikimedia.org wrote:
Another possibility is to shell out to nodejs-based services as an alternative to running them as ongoing web services.
I have a hard time imagining a situation where you can install node and everything else, but would not just apt-get install parsoid https://www.mediawiki.org/wiki/Parsoid/Setup or mathoid. VMs that can run MediaWiki with all bells & whistles start at around $3 per month http://www.ovh.com/us/vps/vps-classic.xml these days, and are likely to become even cheaper.
I believe we can make installing a fully-featured MediaWiki service system as simple as copy&pasting 2-3 lines to a shell, or even executing a remote installer script that runs those lines for you. Additionally, we can offer VM images derived from the same install process through Bitnami or others.
To make this happen, we need to evaluate the options, make a decision and then follow through by making this our recommended and supported installation mechanism & providing a solid upgrade path for existing content.
I created https://phabricator.wikimedia.org/T87774 as a high-level tracking bug for the task of evaluating and deciding on a distribution strategy targeted at VMs.
Gabriel _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Scott,
On Wed, Jan 28, 2015 at 9:55 AM, Scott MacLeod helianth@gmail.com wrote:
Gabriel and Wikimedia developers,
In what ways might you be anticipating developments with SemanticMediaWiki, and in what ways not?
I definitely think that the mechanism needs to support the (optional) installation of SMW or other extensions. Just called this out in https://phabricator.wikimedia.org/T87774.
I'm not 100% sure if that's what you meant though, so please elaborate if you had something else in mind.
Gabriel
Gabriel,
Thanks ... yes, that's what I meant, and I wonder further if SemanticMediaWiki will become very central five or ten years out (might it even displace MediaWiki itself as we know it now)?
Scott
On Wed, Jan 28, 2015 at 10:06 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
Scott,
On Wed, Jan 28, 2015 at 9:55 AM, Scott MacLeod helianth@gmail.com wrote:
Gabriel and Wikimedia developers,
In what ways might you be anticipating developments with
SemanticMediaWiki,
and in what ways not?
I definitely think that the mechanism needs to support the (optional) installation of SMW or other extensions. Just called this out in https://phabricator.wikimedia.org/T87774.
I'm not 100% sure if that's what you meant though, so please elaborate if you had something else in mind.
Gabriel _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jan 28, 2015 at 9:51 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
I have a hard time imagining a situation where you can install node and everything else, but would not just apt-get install parsoid https://www.mediawiki.org/wiki/Parsoid/Setup or mathoid.
If you're not on Debian or Ubuntu. Although "yum install parsiod" or whatever might work on other Linux distros, what if you're on Windows or something more exotic?
If you don't have root access, but you don't need to install nodejs because it is already available.
If you don't have root access, but you can install nodejs manually in ~/bin or the like.
Brad,
On Wed, Jan 28, 2015 at 10:08 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
If you're not on Debian or Ubuntu. Although "yum install parsiod" or whatever might work on other Linux distros, what if you're on Windows or something more exotic?
I think that we can help most users more if we identify the most important use cases and focus on making those *really* easy. The installation in exotic scenarios should still be supported, but I think it's okay if it involves following some instructions manually.
My gut feel is that most users are in the situation of having a free choice of hosting provider or distribution. If we can't find a good solution that satisfies our requirements *and* works well across distributions, then I think focusing on Debian / Ubuntu should be okay.
Gabriel
On Wed, Jan 28, 2015 at 10:27 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
I think that we can help most users more if we identify the most important use cases and focus on making those *really* easy. The installation in exotic scenarios should still be supported, but I think it's okay if it involves following some instructions manually.
While I agree that the most important cases should be *really* easy, I worry about the implication that all other cases (including development of core MediaWiki without using VMs) should necessarily be allowed to be *really* complex.
While I agree that the most important cases should be *really* easy, I worry about the implication that all other cases (including development of core MediaWiki without using VMs) should necessarily be allowed to be *really* complex.
If I'm no longer able to run MediaWiki from a XAMPP installation (as part of the development process) without breaking my fingers due to an overlay complicated setup that would require me to read a book before the first line of code hits the editor then its time to put MW in a box and look for something else.
Cheers
On 1/29/15, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Wed, Jan 28, 2015 at 10:27 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
I think that we can help most users more if we identify the most important use cases and focus on making those *really* easy. The installation in exotic scenarios should still be supported, but I think it's okay if it involves following some instructions manually.
While I agree that the most important cases should be *really* easy, I worry about the implication that all other cases (including development of core MediaWiki without using VMs) should necessarily be allowed to be *really* complex.
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think XAMPP-type setups are actually probably going to adapt well here -- since you have full system access you can install and run NodeJS-based services as well. And an installer frontend can help manage setup so you don't have to manually do much.
My biggest worry is the small installation on a server where the maintainer doesn't have full admin/root access -- shared departmental web servers or shared-PHP hosting services.
-- brion
On Wed, Jan 28, 2015 at 11:16 AM, James HK jamesin.hongkong.1@gmail.com wrote:
While I agree that the most important cases should be *really* easy, I worry about the implication that all other cases (including development
of
core MediaWiki without using VMs) should necessarily be allowed to be *really* complex.
If I'm no longer able to run MediaWiki from a XAMPP installation (as part of the development process) without breaking my fingers due to an overlay complicated setup that would require me to read a book before the first line of code hits the editor then its time to put MW in a box and look for something else.
Cheers
On 1/29/15, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Wed, Jan 28, 2015 at 10:27 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
I think that we can help most users more if we identify the most
important
use cases and focus on making those *really* easy. The installation in exotic scenarios should still be supported, but I think it's okay if it involves following some instructions manually.
While I agree that the most important cases should be *really* easy, I worry about the implication that all other cases (including development
of
core MediaWiki without using VMs) should necessarily be allowed to be *really* complex.
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
since you have full system access you can install and run NodeJS-based services as well. And an installer frontend can help manage setup so you don't have to manually do much.
Well, that's the point from your perspective that might cause no trouble because you know what to do but as a developer who has no particular interest in NodeJs or the inner workings of Parsoid, I'm not interested on how to setup NodeJs or for that matter Parsoid. I'm interested in getting MW to run without hassle and not being occupied by trying to install a tomcat or any other service just to see the bare light of the MW logo.
Cheers
On 1/29/15, Brion Vibber bvibber@wikimedia.org wrote:
I think XAMPP-type setups are actually probably going to adapt well here -- since you have full system access you can install and run NodeJS-based services as well. And an installer frontend can help manage setup so you don't have to manually do much.
My biggest worry is the small installation on a server where the maintainer doesn't have full admin/root access -- shared departmental web servers or shared-PHP hosting services.
-- brion
On Wed, Jan 28, 2015 at 11:16 AM, James HK jamesin.hongkong.1@gmail.com wrote:
While I agree that the most important cases should be *really* easy, I worry about the implication that all other cases (including development
of
core MediaWiki without using VMs) should necessarily be allowed to be *really* complex.
If I'm no longer able to run MediaWiki from a XAMPP installation (as part of the development process) without breaking my fingers due to an overlay complicated setup that would require me to read a book before the first line of code hits the editor then its time to put MW in a box and look for something else.
Cheers
On 1/29/15, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Wed, Jan 28, 2015 at 10:27 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
I think that we can help most users more if we identify the most
important
use cases and focus on making those *really* easy. The installation in exotic scenarios should still be supported, but I think it's okay if it involves following some instructions manually.
While I agree that the most important cases should be *really* easy, I worry about the implication that all other cases (including development
of
core MediaWiki without using VMs) should necessarily be allowed to be *really* complex.
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi!
I believe we can make installing a fully-featured MediaWiki service system as simple as copy&pasting 2-3 lines to a shell, or even executing a remote
I think this is underestimating the issue, unfortunately. I.e., in ideal situation - the user runs the same system, with the same services and permissions, that the shell lines were tested on, it probably would work pretty good. But what if he doesn't? What if he doesn't have root access? Has non-Linux Unix system? Has custom-built VPS system with custom-tailored access/capability permissions? Has Windows (not talking about more exotic systems that do have PHP support)? Has no direct Internet access? Has security settings that further restrict their capabilities? Has some of the libraries/packages that our dependencies' dependencies installed in different versions that support different options/APIs/command-line parameters? The problem would be not in those 3 shell lines, but in the complexity those lines hide and in the assumptions those 3 lines make. The difference is between "if this system runs PHP, you're OK" to "if this system can run this three scripts which runs a dozen of scripts which invoke a dozen of software packages with an unknown number of dependencies each and all of them are OK then you're OK".
The point is more moving parts you add, more potential failures are there, and these potential failures very soon become real ones when users start using it in a wide wild world.
And my concern here is that the users - and, more importantly, potential contributors - faced with these failures, would do what James mentioned - pack it and move on to something else, which still is "if you have running PHP, you're OK".
installer script that runs those lines for you. Additionally, we can offer VM images derived from the same install process through Bitnami or others.
VM solves the dependency/environment issue, but running VM on a constant basis requires some sysadmin skills and knowledge (and much higher hardware/access requirements) which again means people with no sysadmin skills would be cut off.
Hi!
Running Parsoid as a public service (with some soft-ish API limits) would allow us to support the oft-cited user who has a dumb PHP-only box and no means to install a node service, so that has my support; however, I worry that WMF might not be the best organisation to provide this if people wanted it at large for commercial use.
I think the prospect of having publicly-accessible services like Parsoid useable by smaller wiki installer is very cool and exciting. Thought it does not solve all cases - i.e. for inter-company wiki (which I personally used extensively as a medium for capturing internal docs, discussions, plans, etc.) there may be legal and confidentiality reasons that do not allow using services crossing the firewall.
On 2015-01-27 12:51 PM, Stas Malyshev wrote:
Hi!
Running Parsoid as a public service (with some soft-ish API limits) would allow us to support the oft-cited user who has a dumb PHP-only box and no means to install a node service, so that has my support; however, I worry that WMF might not be the best organisation to provide this if people wanted it at large for commercial use.
I think the prospect of having publicly-accessible services like Parsoid useable by smaller wiki installer is very cool and exciting. Thought it does not solve all cases - i.e. for inter-company wiki (which I personally used extensively as a medium for capturing internal docs, discussions, plans, etc.) there may be legal and confidentiality reasons that do not allow using services crossing the firewall.
Companies running internal wikis naturally aren't using shared hosting.
They would probably be better served with alternative setups that make it easy to setup and run the services locally.
Something for things like Vagrant, Docker, Turnkey, etc...
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2015-01-27 11:04 AM, Brion Vibber wrote:
One thing that comes to mind though is something Gabriel mentioned about wanting stateless services for things like image manipulation and citation parsing and whatnot -- in principle many services like this could be opened up to public use.
For instance, a random MediaWiki instance could use a Wikimedia-hosted image scaler or graph rasterizer.
This!
This is something I've thought about too but never got around to writing about.
I found one of Automattic's models rather interesting.
Everyone knows about WordPress.com where they have full free and premium hosting of WordPress (with limits on plugins, etc...).
But another one of their projects is the Jetpack plugin.
The plugin has multiple features that can be enabled and disabled. - Some of them are simple small WordPress plugins that add local features. - Others integrate with services hosted on WordPress.com offering a 3rd-party installation features like WordPress.com hosted stats, use of Automattic's CDN, WordPress.com login, and warnings when your site is offline. - And then there are a few hosted premium features like video hosting and an automated backup service.
Simple extension(s) that quick and easily allow a hosted service to enhance a locally installed MediaWiki installation could be a useful addition to the MediaWiki ecosystem.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
The only true precedent we have here is the public Collection server run by PediaPress, which is a wonderful service used by several hundreds wikis for years. It ensures a comparatively smooth installation of the Collection extension even for the most niche formats. https://www.mediawiki.org/wiki/Extension:Collection#Generating_PDFs.2C_OpenD...
One could perhaps also consider DNSBL services by SpamHaus and others. https://www.mediawiki.org/wiki/Manual:Combating_spam#DNSBL But I don't know how many are using them and they're not really effective, so we don't really have a service comparable to Akismet. The "Antispam" extension claims to be one, but at the moment it's used by 3 wikis only.
Nemo
So if all wikis on world would use this central parsoid, I wouldn't like to see that huge outage when the parsoid server breaks :P
On Wed, Jan 28, 2015 at 8:40 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
The only true precedent we have here is the public Collection server run by PediaPress, which is a wonderful service used by several hundreds wikis for years. It ensures a comparatively smooth installation of the Collection extension even for the most niche formats. https://www.mediawiki.org/wiki/Extension:Collection#Generating_PDFs.2C_OpenD...
One could perhaps also consider DNSBL services by SpamHaus and others. https://www.mediawiki.org/wiki/Manual:Combating_spam#DNSBL But I don't know how many are using them and they're not really effective, so we don't really have a service comparable to Akismet. The "Antispam" extension claims to be one, but at the moment it's used by 3 wikis only.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
We could also try convincing the semi-decent shared hosts like Dreamhost and Linode to run a service of their own for their customers.
That reminds me, I had an idea lying around somewhere about making it possible for things like shared hosts to offer configuration hints to the installer.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2015-01-28 12:08 AM, Petr Bena wrote:
So if all wikis on world would use this central parsoid, I wouldn't like to see that huge outage when the parsoid server breaks :P
On Wed, Jan 28, 2015 at 8:40 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
The only true precedent we have here is the public Collection server run by PediaPress, which is a wonderful service used by several hundreds wikis for years. It ensures a comparatively smooth installation of the Collection extension even for the most niche formats. https://www.mediawiki.org/wiki/Extension:Collection#Generating_PDFs.2C_OpenD...
One could perhaps also consider DNSBL services by SpamHaus and others. https://www.mediawiki.org/wiki/Manual:Combating_spam#DNSBL But I don't know how many are using them and they're not really effective, so we don't really have a service comparable to Akismet. The "Antispam" extension claims to be one, but at the moment it's used by 3 wikis only.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 28 January 2015 at 08:13, Daniel Friesen daniel@nadir-seen-fire.com wrote:
We could also try convincing the semi-decent shared hosts like Dreamhost and Linode to run a service of their own for their customers.
Yes, reaching out to a shared hosting company or two is definitely something to do at this stage!
Do WordPress talk to hosting companies? They may be able to offer ideas on what hosting companies want as well.
- d.
wikitech-l@lists.wikimedia.org