Re: svn commit: r1733537 - /httpd/httpd/trunk/support/ab.c

[Yann Ylavic]

On Tue, May 24, 2016 at 9:01 PM, William A Rowe Jr  wrote:
>>
>> +/*
>> + * Similar to standard strstr() but we ignore case in this version.
>> + * Copied from ap_strcasestr().
>> + */
>> +static char *xstrcasestr(const char *s1, const char *s2)
>> +{
[]
>> +}
>
> Two thoughts.  It seems this is a good candidate for APR 1.6
> apr_cstr_casestr?

+1

>
> Second thought - it seems like the implement locally -> push to apr model
> is good for as far as it gets us, but we don't want our httpd users to be in
> a rat race to chase new apr[-util] behavior unless they are chasing a new
> httpd optional module or feature.
>
> What if we were to refactor some of server/util*.c into a localized
> ap-httpd.so
> library that could be consumed by httpd core, as well as our support
> utilities
> and third parties who want our very http-specific functions that are simply
> not
> good fits for apr?

+1

We'd probably need to be able to update ap-httpd for the needs of the
next httpd release (with the same API/ABI-changes constraints for
both, i.e. httpd's), and hence ship them together.

That would also help implementing useful things to/in both httpd and
APR (as trunk/next proposal), and use them immediatly in httpd without
requiring APR next or putting stub in httpd core (the stub would be in
ap-httpd, eg. like the ap_cstr_casecmp we are currently discussing,
and once httpd requires the next APR version for other reasons, this
stub would become a single #define).

Regards,
Yann.

Re: svn commit: r1745582 - /httpd/httpd/branches/2.4.x/STATUS

[Yann Ylavic]

On Thu, May 26, 2016 at 3:37 PM, William A Rowe Jr  wrote:
> On Thu, May 26, 2016 at 8:24 AM, William A Rowe Jr 
> wrote:
>>
>>
>>> Excellent, but one big issue, namespace collision.
>>>
>>> [...]
>>
>> would be the proper doxygen, to dissuade users from directly consuming
>> ap_ flavor.  However we would not drop the ap_flavor until 2.6.x so that
>> any
>> later updates of 2.4.x would still retain this function.
>>
>> When the user updates to apr 1.6.x without altering httpd 2.4.21, we don't
>> want the symbol collisions between the httpd binary and libapr-1.so
>> library.
>> The effects vary between OS architectures, from inconvenient to fatal to
>> entirely benign (win32 or os2 2-level namespaces).
>>
>> WDYT?
>
>
> I overlooked something, we can simplify... in the header...
>
> +#if !APR_VERSION_AT_LEAST(1,6,0)
> +/**
> + * Known-fast version of strcasecmp(): ASCII case-folding, POSIX compliant
> + * @param s1 The 1st string to compare
> + * @param s2 The 2nd string to compare
> + * @return 0 if s1 is lexicographically equal to s2 ignoring case;
> + * non-0 otherwise.
> + */
> +#define apr_cstr_casecmp(s1, s2) ap_cstr_casecmp(s1, s2)
> +#endif

Why would we provide an APR thing in httpd ?

> +
> +/**
> + * HTTPD Internal function, do not use. @see apr_cstr_casecmp instead
> + * @deprecated Internal function will be absent from httpd 2.6 / 3.0.
> + */
> +AP_DECLARE(int) ap_cstr_casecmp(const char *s1, const char *s2);
>
> Note the function declaration is a constant, above, not conditional.
>
> In the C sources...
>
> +#if APR_VERSION_AT_LEAST(1,6,0)
> +int ap_cstr_casecmp(const char *s1, const char *s2)
> +{
> +return apr_cstr_casecmp(const char *s1, const char *s2);
> +}
> +#else
> +int ap_cstr_casecmp(const char *s1, const char *s2)
> +{
> ... full implementation.
>
> This ensures any earlier module code linked to ap_cstr... will still
> resolve that symbol, while transitioning to a call out to apr_cstr
> flavor once httpd is recompiled with the newer apr.
>
> This seems like the best transitional approach.

ISTM that modules could use ap_cstr_casecmp() w/o ever transitioning,
what's the downside since we will never deprecate it, or will we?

BTW, why not simply:
#if APR_VERSION_AT_LEAST(1,6,0)
#define ap_cstr_casecmp apr_cstr_casecmp
#else
AP_DECLARE(int) ap_cstr_casecmp(const char *s1, const char *s2);
#endif
so that we don't provide something in the APR namespace?

Regards,
Yann.

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[William A Rowe Jr]

On Wed, May 25, 2016 at 10:11 AM, William A Rowe Jr 
wrote:

>
> So let's try this... would 2.2.x maintainers and PMC folks please answer
> this
> poll -if- you have an intention to help throughout the wind-down of 2.2.x,
> since
> this is all predicated on having committed-committers to participate.
> This isn't
> to say folks refuse to participate after the time period you offer, but
> for how long
> you are personally prepared to participate.  [If you aren't a 2.2.x legacy
> branch
> participant, testing RCs or applying backports, then no response is
> needed.]
>
>  *) I intend to help maintain/test 2.2.x releases over the next [] mos
>
>  *) I intend to backport/review 2.2.x security patches over the next
> [] mos
>

With the holiday weekend here in the US, I'll let the poll run a full week,
and cross-tabulate the results for us this coming Wednesday.

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Yann Ylavic]

On Wed, May 25, 2016 at 5:11 PM, William A Rowe Jr  wrote:
>
*) I intend to help maintain/test 2.2.x releases over the next [18] mos
*) I intend to backport/review 2.2.x security patches over the next [18] mos

Re: Module Development - Advice Needed

[Nick Kew]

On Thu, 2016-05-26 at 22:44 +, Van Ulden, Joost (NRCan/RNCan) wrote:

> I approached a couple of folks at ApacheCon in Vancouver about some
> work that I am involved with that would benefit from an httpd module.
> I am sending this message to the list to provide more information, and
> to seek advice on how we should proceed.
> 
> We are developing a format we call “Map Markup Language”, or MapML.
> The objective of this format is to describe Web map semantics – that
> is scale / zoom, projection, extent, features, styles, licenses,
> legends in the context of a hypermedia media type that can be
> manipulated / interacted with through the uniform interface alone.  We
> would like to eventually register the format as text/mapml.

This is seriously interesting.  I need to take a look, and will
be well pleased if I can find time to take an active interest.

> A Java servlet prototype for this functionality is available:

I have yet to look at that.  Would you plan the module and servlet
to grow in parallel as alternative implementations, or each to take
its own path?  Presumably there is something to be gained with the
two alternative implementations?

> We would like some advice on how to proceed with the development of a
> module. For instance should we pursue this as a third-party module?
> Can we tap into the community for development assistance if we don’t
> have the required skills in-house? Any advice would be appreciated.

You've had a couple of suggestions from Bill: I would agree that
either github or the apache incubator make sense and are options
worth considering (the latter could lead to it eventually becoming
a sub-project of httpd itself).

I would think, let the servlet be your guide.  If it's thriving
then you have a good model.  If not, you learn lessons from it.
Either way, thanks for posting to tell us about your project!

As Jacob points out, the modules-dev list is a good resource
for technical help.  It's low-traffic, but still populated by
a fair few people willing and able to help.

-- 
Nick Kew

Re: Module Development - Advice Needed

[Jacob Champion]

On 05/26/2016 08:18 PM, William A Rowe Jr wrote:

The users list is the best place to ask for clarification and guidance,
users are not exclusively admins, they include module authors,
troubleshooters, even a testing community.


In addition to users@, there is also a modules-dev@ list for httpd. It 
has the advantage of being more tailored to module writers, and the 
disadvantage of being very, very quiet.


--Jacob