You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2018/04/18 16:55:33 UTC
Expanding httpd adoption internationally
On Wed, Apr 18, 2018 at 11:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> 1. nginx, particularly, does a LOT of promoting, marketing, PR, etc...
> We don't. They get to promote their FUD all the time and remain
> pretty much unchallenged.
I'd like to break out and break down specific nginx FUD... but much
moreso, our failure to meet a market of administrators who have
their choice and don't choose httpd... and take these apart as specific
httpd dev@ threads. So I'll start with this;
httpd: English-only for administrators
nginx: Internationalized admin, esp non-latin support
IIS: Internationalized admin, esp ISO-2022 language support
Any questions?
Re: Expanding httpd adoption internationally - POC
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 24, 2018 at 2:41 AM, Rainer Jung <ra...@kippdata.de> wrote:
> Am 24.04.2018 um 07:20 schrieb Marion et Christophe JAILLET:
>>
>> Le 24/04/2018 à 02:58, William A Rowe Jr a écrit :
>>>
>>> On Thu, Apr 19, 2018 at 12:20 AM, Marion et Christophe JAILLET
>>> <ch...@wanadoo.fr> wrote:
>>>>
>>>> Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :
>>>>>
>>>>> On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <ni...@apache.org> wrote:
>>>>>>>
>>>>>>> I suspect the straightforward way to do this, in 2.6/3.0, will be to
>>>>>>> add
>>>>>>> an
>>>>>>> i18n table of the error log strings extracted from and indexed by
>>>>>>> those
>>>>>>> APLOGNO() entries. No match? Default English message.
>>>>>>
>>>>>> Please, not without an overhaul of APLOGNO to automate it a lot
>>>>>> better!
>>>>>> The time to devise your error message is when coding an original
>>>>>> ap_log_*error, not retrospectively once a number has been generated!
>>>>>
>>>>> ++1
>>>>
>>>> This could be achieved easily by just adding in 'log_error_core()':
>>>> (+ a few lines to initialize gettext in main() + a few lines to get a
>>>> pool
>>>> in 'log_error_core()' (i.e. p below))
>>>>
>>>> /* Check if we have a leading AHnnnnn: header */
>>>> if (p &&
>>>> fmt[0] == 'A' &&
>>>> fmt[1] == 'H' &&
>>>> apr_isdigit(fmt[2]) &&
>>>> apr_isdigit(fmt[3]) &&
>>>> apr_isdigit(fmt[4]) &&
>>>> apr_isdigit(fmt[5]) &&
>>>> apr_isdigit(fmt[6]) &&
>>>> fmt[7] == ':' &&
>>>> fmt[8] == ' ') {
>>>> const char *tmp;
>>>>
>>>> /* Get the translation of the message itself */
>>>> tmp = gettext(&fmt[9]);
>>>>
>>>> /* Rewrite the format string with the translated message */
>>>> fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
>>>> printf("tmp: %s\n", fmt);
>>>> }
>>>>
>>>> That's all.
>>>> If interested by this approach, I can give a full working patch.
>>>
>>> While we are unconcerned whether build tooling is GPL, we are very
>>> concerned
>>> that we retain license and copyright of that output, and that linking
>>> system GPL
>>> code does not alter our license.
>>>
>>> As a GPL toolchain and call, this seems to require additional research.
>>>
>>> If the tooling is clean and the gettext() call is not, then I could
>>> fully support
>>> following GPL gettext conversion file conventions in any custom code we
>>> create.
>>>
>> I'm not really a license man, but as far as I understand, the gettext
>> library itself is LGPL, not GPL
>> (https://www.gnu.org/software/gettext/manual/html_node/Licenses.html). I
>> suppose that this is fine with the Apache license (but once again, I'm not a
>> license man...)
>
>
> Since by
>
> https://www.apache.org/legal/resolved.html
>
> LGPL is a prohibited license (for releasing ASF code under that license), I
> guess the following text from the same page applies:
>
> ===========================
>
> Can Apache projects rely on components under prohibited licenses?
>
> Apache projects cannot distribute any such components within their releases.
> However, if the component is only needed for optional features, a project
> can provide the user with instructions on how to obtain and install the
> non-included work. Optional means that the component is not required for
> standard use of the product or for the product to achieve a desirable level
> of quality. The question to ask yourself in this situation is:
>
> "Will the majority of users want to use my product without adding the
> optional components?"
>
> ===========================
>
> More details are at
>
> https://issues.apache.org/jira/browse/LEGAL-192
>
> I (ANAL) think that the key point here is that downstreams that want to
> distribute a binary version of the web server might need to include the LGPL
> library in their distribution and at that point would no longer be free to
> choose any license they want.
>
> If the library were part of the OS of any target platform and thus would not
> be need to get bundled, things might be different.
>
> Surely logging is at the core of the web server. Whether internationalizing
> logging would be really optional once we introduce it is at least
> questionable. IMHO "the majority of users *do not * want to use my product
> without adding the optional components".
There is a secondary consideration to gettext(), there is only one language
of localization. In a multi-tenant environment like httpd, where a number of
different administrators may operate a distinct subset of the virtual hosts
or URI space, per-server error log language scope makes a lot of sense.
The gettext() API doesn't do this.
Re: Expanding httpd adoption internationally - POC
Posted by Rainer Jung <ra...@kippdata.de>.
Am 24.04.2018 um 07:20 schrieb Marion et Christophe JAILLET:
> Le 24/04/2018 à 02:58, William A Rowe Jr a écrit :
>> On Thu, Apr 19, 2018 at 12:20 AM, Marion et Christophe JAILLET
>> <ch...@wanadoo.fr> wrote:
>>> Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :
>>>> On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <ni...@apache.org> wrote:
>>>>>> I suspect the straightforward way to do this, in 2.6/3.0, will be
>>>>>> to add
>>>>>> an
>>>>>> i18n table of the error log strings extracted from and indexed by
>>>>>> those
>>>>>> APLOGNO() entries. No match? Default English message.
>>>>> Please, not without an overhaul of APLOGNO to automate it a lot
>>>>> better!
>>>>> The time to devise your error message is when coding an original
>>>>> ap_log_*error, not retrospectively once a number has been generated!
>>>> ++1
>>> This could be achieved easily by just adding in 'log_error_core()':
>>> (+ a few lines to initialize gettext in main() + a few lines to get a
>>> pool
>>> in 'log_error_core()' (i.e. p below))
>>>
>>> /* Check if we have a leading AHnnnnn: header */
>>> if (p &&
>>> fmt[0] == 'A' &&
>>> fmt[1] == 'H' &&
>>> apr_isdigit(fmt[2]) &&
>>> apr_isdigit(fmt[3]) &&
>>> apr_isdigit(fmt[4]) &&
>>> apr_isdigit(fmt[5]) &&
>>> apr_isdigit(fmt[6]) &&
>>> fmt[7] == ':' &&
>>> fmt[8] == ' ') {
>>> const char *tmp;
>>>
>>> /* Get the translation of the message itself */
>>> tmp = gettext(&fmt[9]);
>>>
>>> /* Rewrite the format string with the translated message */
>>> fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
>>> printf("tmp: %s\n", fmt);
>>> }
>>>
>>> That's all.
>>> If interested by this approach, I can give a full working patch.
>> While we are unconcerned whether build tooling is GPL, we are very
>> concerned
>> that we retain license and copyright of that output, and that linking
>> system GPL
>> code does not alter our license.
>>
>> As a GPL toolchain and call, this seems to require additional research.
>>
>> If the tooling is clean and the gettext() call is not, then I could
>> fully support
>> following GPL gettext conversion file conventions in any custom code
>> we create.
>>
> I'm not really a license man, but as far as I understand, the gettext
> library itself is LGPL, not GPL
> (https://www.gnu.org/software/gettext/manual/html_node/Licenses.html). I
> suppose that this is fine with the Apache license (but once again, I'm
> not a license man...)
Since by
https://www.apache.org/legal/resolved.html
LGPL is a prohibited license (for releasing ASF code under that
license), I guess the following text from the same page applies:
===========================
Can Apache projects rely on components under prohibited licenses?
Apache projects cannot distribute any such components within their
releases. However, if the component is only needed for optional
features, a project can provide the user with instructions on how to
obtain and install the non-included work. Optional means that the
component is not required for standard use of the product or for the
product to achieve a desirable level of quality. The question to ask
yourself in this situation is:
"Will the majority of users want to use my product without adding
the optional components?"
===========================
More details are at
https://issues.apache.org/jira/browse/LEGAL-192
I (ANAL) think that the key point here is that downstreams that want to
distribute a binary version of the web server might need to include the
LGPL library in their distribution and at that point would no longer be
free to choose any license they want.
If the library were part of the OS of any target platform and thus would
not be need to get bundled, things might be different.
Surely logging is at the core of the web server. Whether
internationalizing logging would be really optional once we introduce it
is at least questionable. IMHO "the majority of users *do not * want to
use my product without adding the optional components".
Regards,
Rainer
Re: Expanding httpd adoption internationally - POC
Posted by Marion et Christophe JAILLET <ch...@wanadoo.fr>.
Le 24/04/2018 à 02:58, William A Rowe Jr a écrit :
> On Thu, Apr 19, 2018 at 12:20 AM, Marion et Christophe JAILLET
> <ch...@wanadoo.fr> wrote:
>> Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :
>>> On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <ni...@apache.org> wrote:
>>>>> I suspect the straightforward way to do this, in 2.6/3.0, will be to add
>>>>> an
>>>>> i18n table of the error log strings extracted from and indexed by those
>>>>> APLOGNO() entries. No match? Default English message.
>>>> Please, not without an overhaul of APLOGNO to automate it a lot better!
>>>> The time to devise your error message is when coding an original
>>>> ap_log_*error, not retrospectively once a number has been generated!
>>> ++1
>> This could be achieved easily by just adding in 'log_error_core()':
>> (+ a few lines to initialize gettext in main() + a few lines to get a pool
>> in 'log_error_core()' (i.e. p below))
>>
>> /* Check if we have a leading AHnnnnn: header */
>> if (p &&
>> fmt[0] == 'A' &&
>> fmt[1] == 'H' &&
>> apr_isdigit(fmt[2]) &&
>> apr_isdigit(fmt[3]) &&
>> apr_isdigit(fmt[4]) &&
>> apr_isdigit(fmt[5]) &&
>> apr_isdigit(fmt[6]) &&
>> fmt[7] == ':' &&
>> fmt[8] == ' ') {
>> const char *tmp;
>>
>> /* Get the translation of the message itself */
>> tmp = gettext(&fmt[9]);
>>
>> /* Rewrite the format string with the translated message */
>> fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
>> printf("tmp: %s\n", fmt);
>> }
>>
>> That's all.
>> If interested by this approach, I can give a full working patch.
> While we are unconcerned whether build tooling is GPL, we are very concerned
> that we retain license and copyright of that output, and that linking system GPL
> code does not alter our license.
>
> As a GPL toolchain and call, this seems to require additional research.
>
> If the tooling is clean and the gettext() call is not, then I could
> fully support
> following GPL gettext conversion file conventions in any custom code we create.
>
I'm not really a license man, but as far as I understand, the gettext
library itself is LGPL, not GPL
(https://www.gnu.org/software/gettext/manual/html_node/Licenses.html). I
suppose that this is fine with the Apache license (but once again, I'm
not a license man...)
CJ
Re: Expanding httpd adoption internationally - POC
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Apr 19, 2018 at 12:20 AM, Marion et Christophe JAILLET
<ch...@wanadoo.fr> wrote:
> Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :
>>
>> On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <ni...@apache.org> wrote:
>>>>
>>>> I suspect the straightforward way to do this, in 2.6/3.0, will be to add
>>>> an
>>>> i18n table of the error log strings extracted from and indexed by those
>>>> APLOGNO() entries. No match? Default English message.
>>>
>>> Please, not without an overhaul of APLOGNO to automate it a lot better!
>>> The time to devise your error message is when coding an original
>>> ap_log_*error, not retrospectively once a number has been generated!
>>
>> ++1
>
> This could be achieved easily by just adding in 'log_error_core()':
> (+ a few lines to initialize gettext in main() + a few lines to get a pool
> in 'log_error_core()' (i.e. p below))
>
> /* Check if we have a leading AHnnnnn: header */
> if (p &&
> fmt[0] == 'A' &&
> fmt[1] == 'H' &&
> apr_isdigit(fmt[2]) &&
> apr_isdigit(fmt[3]) &&
> apr_isdigit(fmt[4]) &&
> apr_isdigit(fmt[5]) &&
> apr_isdigit(fmt[6]) &&
> fmt[7] == ':' &&
> fmt[8] == ' ') {
> const char *tmp;
>
> /* Get the translation of the message itself */
> tmp = gettext(&fmt[9]);
>
> /* Rewrite the format string with the translated message */
> fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
> printf("tmp: %s\n", fmt);
> }
>
> That's all.
> If interested by this approach, I can give a full working patch.
While we are unconcerned whether build tooling is GPL, we are very concerned
that we retain license and copyright of that output, and that linking system GPL
code does not alter our license.
As a GPL toolchain and call, this seems to require additional research.
If the tooling is clean and the gettext() call is not, then I could
fully support
following GPL gettext conversion file conventions in any custom code we create.
Re: Expanding httpd adoption internationally - POC
Posted by Eric Covener <co...@gmail.com>.
On Thu, Apr 19, 2018 at 10:24 AM, Eric Covener <co...@gmail.com> wrote:
> On Thu, Apr 19, 2018 at 9:38 AM, Eric Covener <co...@gmail.com> wrote:
>>> If using gettext, there are some tools to check for that.
>>
>> Would be nice to put some feelers out to $bigcos to make sure we
>> choose a format they'd accomoddate [if they were otherwise willing to
>> donate a one-time translation]
>>
>
> The IBM formats do not look very promising w/o import/export.
> (and I didn't even consider how I'd get someone to pay)
Strike that, I realize now they assign proprietary identifiers to
normal formats. So if we use gettext IBM would be a candidate.
--
Eric Covener
covener@gmail.com
Re: Expanding httpd adoption internationally - POC
Posted by Eric Covener <co...@gmail.com>.
On Thu, Apr 19, 2018 at 9:38 AM, Eric Covener <co...@gmail.com> wrote:
>> If using gettext, there are some tools to check for that.
>
> Would be nice to put some feelers out to $bigcos to make sure we
> choose a format they'd accomoddate [if they were otherwise willing to
> donate a one-time translation]
>
The IBM formats do not look very promising w/o import/export.
(and I didn't even consider how I'd get someone to pay)
Re: Expanding httpd adoption internationally - POC
Posted by Eric Covener <co...@gmail.com>.
> If using gettext, there are some tools to check for that.
Would be nice to put some feelers out to $bigcos to make sure we
choose a format they'd accomoddate [if they were otherwise willing to
donate a one-time translation]
--
Eric Covener
covener@gmail.com
Re: Expanding httpd adoption internationally - POC
Posted by Marion et Christophe JAILLET <ch...@wanadoo.fr>.
Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :
> On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <ni...@apache.org> wrote:
>>> I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
>>> i18n table of the error log strings extracted from and indexed by those
>>> APLOGNO() entries. No match? Default English message.
>> Please, not without an overhaul of APLOGNO to automate it a lot better!
>> The time to devise your error message is when coding an original
>> ap_log_*error, not retrospectively once a number has been generated!
> ++1
This could be achieved easily by just adding in 'log_error_core()':
(+ a few lines to initialize gettext in main() + a few lines to get a
pool in 'log_error_core()' (i.e. p below))
/* Check if we have a leading AHnnnnn: header */
if (p &&
fmt[0] == 'A' &&
fmt[1] == 'H' &&
apr_isdigit(fmt[2]) &&
apr_isdigit(fmt[3]) &&
apr_isdigit(fmt[4]) &&
apr_isdigit(fmt[5]) &&
apr_isdigit(fmt[6]) &&
fmt[7] == ':' &&
fmt[8] == ' ') {
const char *tmp;
/* Get the translation of the message itself */
tmp = gettext(&fmt[9]);
/* Rewrite the format string with the translated message */
fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
printf("tmp: %s\n", fmt);
}
That's all.
If interested by this approach, I can give a full working patch.
the po file can then be generated with things like:
xgettext server/core.c -kap_log_error:5
This could be a good starting point which does not need to refactor
everything, at the cost of some cycles and some additional memory.
>
>> In fact, it would call for a refactoring of the entire ap_log framework
>> away from printf-style format strings and vars, that’ll inevitably give rise
>> to a whole new level of awkwardness. Which seems like a very bad
>> effort-to-gain ratio. -1 to embarking on this, unless you want to
>> create a new experimental branch to play in.
> I agree this is not a trivial change. There are specific risks of corrupting
> one language's %tokens in a way that segfaults the runtime (switch any
> %d for a %s and boom.) The resulting table is absolutely a root admin's
> directive, must not be manipulated by any other than root.
>
If using gettext, there are some tools to check for that.
CJ
Re: Expanding httpd adoption internationally
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <ni...@apache.org> wrote:
>
>> I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
>> i18n table of the error log strings extracted from and indexed by those
>> APLOGNO() entries. No match? Default English message.
>
> Please, not without an overhaul of APLOGNO to automate it a lot better!
> The time to devise your error message is when coding an original
> ap_log_*error, not retrospectively once a number has been generated!
++1
> In fact, it would call for a refactoring of the entire ap_log framework
> away from printf-style format strings and vars, that’ll inevitably give rise
> to a whole new level of awkwardness. Which seems like a very bad
> effort-to-gain ratio. -1 to embarking on this, unless you want to
> create a new experimental branch to play in.
I agree this is not a trivial change. There are specific risks of corrupting
one language's %tokens in a way that segfaults the runtime (switch any
%d for a %s and boom.) The resulting table is absolutely a root admin's
directive, must not be manipulated by any other than root.
> BTW, my previous reply in this thread was predicated on your reference
> to “specific nginx FUD”. I misread your post as describing some FUD.
No worries.
> Come to think of it, from memory of developing nginx modules, their
> error message framework looks a lot like ours. It's in english too.
> Though I never delved into its internals.
Anyone with more info feel free to share. I can state for a fact your
IIS error messages are localized.
Re: Expanding httpd adoption internationally
Posted by Nick Kew <ni...@apache.org>.
> I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
> i18n table of the error log strings extracted from and indexed by those
> APLOGNO() entries. No match? Default English message.
Please, not without an overhaul of APLOGNO to automate it a lot better!
The time to devise your error message is when coding an original
ap_log_*error, not retrospectively once a number has been generated!
In fact, it would call for a refactoring of the entire ap_log framework
away from printf-style format strings and vars, that’ll inevitably give rise
to a whole new level of awkwardness. Which seems like a very bad
effort-to-gain ratio. -1 to embarking on this, unless you want to
create a new experimental branch to play in.
BTW, my previous reply in this thread was predicated on your reference
to “specific nginx FUD”. I misread your post as describing some FUD.
Come to think of it, from memory of developing nginx modules, their
error message framework looks a lot like ours. It's in english too.
Though I never delved into its internals.
—
Nick Kew
Re: Expanding httpd adoption internationally
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Apr 18, 2018 at 1:53 PM, Marion et Christophe JAILLET
<ch...@wanadoo.fr> wrote:
> Le 18/04/2018 à 20:00, William A Rowe Jr a écrit :
>>
>> Localizing our error messages alone would go a long ways to being
>> friendly to non-english speaking administrators. If we don't want to
>> bother, we can expect for our software to be further marginalized.
>
> you mean something like instrumenting our logging functions and use, for
> example, gettext as a translation mechanism?
>
> As an example on 1 file, with one logging function, something like:
> xgettext server/core.c -kap_log_error:5 -o -
> With this example, APLOGNO() are swallowed, because xgettext is not aware of
> the stringizing done in APLOGNO(), but we could try to find a way to deal
> with it.
I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
i18n table of the error log strings extracted from and indexed by those
APLOGNO() entries. No match? Default English message.
Load this all in at startup as a hash based on the error language
requested by-vhost. So the es.example.com vhost might deliver
a host error log populated with Spanish, while the primary www.
host and global error log are in other languages. Index the various
hash string tables by language code to prevent any duplicates from
being loaded.
This makes the individual allocations even more critical, as we have
an entire set of %s %d tokens listed in that table. Adding an extra %d
element would call for a new APLOGNO() allocation.
At that point, the entire table can be programmatically translated
(somewhat goofy results) and then refined with sensible text.
The more challenging aspect are the number of "running" "stopped"
"restarting" sorts of %s text patterns which aught to also be
translated. They fall in the wrong position of some sentences, so
for a handful of these, replacing them with three distinct error log
messages might be the easier way to proceed. Otherwise, we
could have some secondary translation table for those word:word
entities, probably not associated to any specific APLOGNO.
Re: Expanding httpd adoption internationally
Posted by Marion et Christophe JAILLET <ch...@wanadoo.fr>.
Le 18/04/2018 à 20:00, William A Rowe Jr a écrit :
> I'm speaking of personal i18n experience as a Windows developer, and
> assigning support for Cyrillic-based languages in nginx that I've presumed
> exist (I've never researched the software but am familiar with the origins.)
>
> [...]
>
> In short, we demand admins read their httpd error log in English, even
> where the underlying cause has been rendered in their local language
> by the underlying operating system. (OS error messaging falls apart in
> mass hosting where readers of different languages are hosted on the
> same box, but that's an unusual situation, based on mass-vhoster
> marketing alone.)
>
> Localizing our error messages alone would go a long ways to being
> friendly to non-english speaking administrators. If we don't want to
> bother, we can expect for our software to be further marginalized.
you mean something like instrumenting our logging functions and use, for
example, gettext as a translation mechanism?
As an example on 1 file, with one logging function, something like:
xgettext server/core.c -kap_log_error:5 -o -
With this example, APLOGNO() are swallowed, because xgettext is not
aware of the stringizing done in APLOGNO(), but we could try to find a
way to deal with it.
CJ
Re: Expanding httpd adoption internationally
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
I'm speaking of personal i18n experience as a Windows developer, and
assigning support for Cyrillic-based languages in nginx that I've presumed
exist (I've never researched the software but am familiar with the origins.)
IIS/Windows long offered robust support to the multibyte character development
spheres, along with localized error messages and JP-2022 rendering. Also enjoys
a very long history of R-T-L text support.
This is a very dated report but is still useful in illustrating early nginx
vs IIS vs Apache httpd adoption, which has always mapped well into
my assumptions;
https://w3techs.com/blog/entry/most_popular_web_servers_by_country
In short, we demand admins read their httpd error log in English, even
where the underlying cause has been rendered in their local language
by the underlying operating system. (OS error messaging falls apart in
mass hosting where readers of different languages are hosted on the
same box, but that's an unusual situation, based on mass-vhoster
marketing alone.)
Localizing our error messages alone would go a long ways to being
friendly to non-english speaking administrators. If we don't want to
bother, we can expect for our software to be further marginalized.
On Wed, Apr 18, 2018 at 12:45 PM, Nick Kew <ni...@apache.org> wrote:
>
>> On 18 Apr 2018, at 17:55, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> So I'll start with this;
>
> Erm, would you like to cite a source for that claim? I confess it’s not one I’ve seen.
> I don’t follow either nginx marketing nor any fan club they might have.
>
> If what you refer to is the latter, it’s natural for any incumbent market-leader
> to feature in such unflattering comparisons, while challenger communities
> have more tendency to be evangelical. Though nowadays nginx should be
> up there with us on the wrong side of challenger comparisons!
>
> —
> Nick Kew
Re: Expanding httpd adoption internationally
Posted by Nick Kew <ni...@apache.org>.
> On 18 Apr 2018, at 17:55, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> So I'll start with this;
Erm, would you like to cite a source for that claim? I confess it’s not one I’ve seen.
I don’t follow either nginx marketing nor any fan club they might have.
If what you refer to is the latter, it’s natural for any incumbent market-leader
to feature in such unflattering comparisons, while challenger communities
have more tendency to be evangelical. Though nowadays nginx should be
up there with us on the wrong side of challenger comparisons!
—
Nick Kew