Re: Module Development - Advice Needed
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
Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)
Am 25.05.2016 um 18:11 schrieb William A Rowe Jr: *) I intend to help maintain/test 2.2.x releases over the next [12] mos *) I intend to backport/review 2.2.x security patches over the next [18] mos Rainer
Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)
On 5/25/2016 8:11 AM, William A Rowe Jr wrote: *) I intend to help maintain/test 2.2.x releases over the next [_6__] mos *) I intend to backport/review 2.2.x security patches over the next [_0__] mos
Re: Module Development - Advice Needed
On May 26, 2016 5:44 PM, "Van Ulden, Joost (NRCan/RNCan)" < joost.vanul...@canada.ca> wrote: > > We want to develop an httpd module, “mod_mapml” which will allow the admin to configure MapML responses over a map tile cache, using one or more URI templates as configuration parameters. A Java servlet prototype for this functionality is available: https://github.com/Maps4HTML/MapMLServer. (For the servlet, the parameters are passed via web.xml). > 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. 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. I'd suggest starting with a clearly licensed github repo of your efforts and encourage others to help fom the start in a public way. Httpd project here has two paths, we have the core httpd package distribution, but we have also championed add in modules. An example would be mod_proxy_fcgi, which is in the core bundle, and mod_fcgid, which is a separate download. It is probably easier to ask dev to consider your module for project adoption here once there is a proof of concept/first draft of the working module. There are hundreds of third party modules, and we adopt relatively few of these, but you should be able to create a community around your efforts whether it is at this project, or external. Yet another option is incubator.apache.org, and launch an independent project as the add in module, under the Apache License 2.0 and the Apache governance model. The gene...@incubator.apache.org list is the starting point for all such efforts. If you were targeting httpd plus other server frameworks, it is probably the best fit at the ASF. Cheers Bill
Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)
On Wed, May 25, 2016 at 11:11 AM, 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: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)
*) I intend to help maintain/test 2.2.x releases over the next [_12___] mos *) I intend to backport/review 2.2.x security patches over the next [_18___] mos -- Daniel Ruggeri
Module Development - Advice Needed
Hi all, 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. The niche for the format is best described as "HTML, but for maps". The draft, and evolving, specification for the format can be found here: http://maps4html.github.io/MapML/spec/, which is one of a group of repos belonging to the W3C Maps for HTML Community Group: https://github.com/Maps4HTML. We want to develop an httpd module, "mod_mapml" which will allow the admin to configure MapML responses over a map tile cache, using one or more URI templates as configuration parameters. A Java servlet prototype for this functionality is available: https://github.com/Maps4HTML/MapMLServer. (For the servlet, the parameters are passed via web.xml). Examples of MapML responses can be elicited from a running instances of that servlet here, for example: http://geogratis.gc.ca/mapml/osm/?xmin=9720501&ymin=12017514&xmax=9721201&ymax=12017914&zoom=17&projection=OSMTILE or http://geogratis.gc.ca/mapml/fdr_current/?xmin=2312&ymin=2582&xmax=2952&ymax=3062&zoom=2&projection=CBMTILE 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. Regards, Joost van Ulden Project Advisor, Earth Sciences Sector Natural Resources Canada / Government of Canada joost.vanul...@canada.ca / Tel: 778-960-9248 Conseiller à la gestion de projets, Secteur des sciences de la Terre Ressources naturelles Canada / Gouvernement du Canada joost.vanul...@canada.ca / Tél. : 778-960-9248
Re: svn commit: r1745582 - /httpd/httpd/branches/2.4.x/STATUS
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
+
+/**
+ * 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.
Re: svn commit: r1745582 - /httpd/httpd/branches/2.4.x/STATUS
Premature ctrl+enter... sorry about that... +#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) > ++/** * Known-fast version of strcasecmp(): ASCII case-folding, POSIX > compliant > +AP_DECLARE(int) ap_cstr_casecmp(const char *s1, const char *s2); > > On Thu, May 26, 2016 at 3:52 AM, wrote: > >> Author: jailletc36 >> Date: Thu May 26 08:52:09 2016 >> New Revision: 1745582 >> >> URL: http://svn.apache.org/viewvc?rev=1745582&view=rev >> Log: >> Proposal >> >> Modified: >> httpd/httpd/branches/2.4.x/STATUS >> >> Modified: httpd/httpd/branches/2.4.x/STATUS >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1745582&r1=1745581&r2=1745582&view=diff >> >> == >> --- httpd/httpd/branches/2.4.x/STATUS (original) >> +++ httpd/httpd/branches/2.4.x/STATUS Thu May 26 08:52:09 2016 >> @@ -188,6 +188,21 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: >> 2.4.x patch: trunk works >> +1: jailletc36, >> >> + *) core: ASCII string comparison functions optimized speed. >> + This proposal includes and renames ap_casecmpstr[n] functions >> available >> + in trunk. >> + The proposed names are the ones used in APR for the same kind of >> functions. >> + In order to avoid some new ap_ functions (which are just copies of >> what is >> + available in APR 1.6.0+), I propose to use exactly the same names >> and only >> + declare and define the functions in httpd if not available in APR. >> + The same approach has already been used for apr_time_from_msec() >> for example. >> + Also note that the implementation in APR and in httpd are slighly >> different. >> + If/when aggreed on this backport and function names in httpd, then >> trunk should >> + be upgraded accordingly. Uses of the functions could then be >> backported. >> + trunk patch: ? >> + 2.4.x patch: >> http://home.apache.org/~jailletc36/apr_cstr_casecmp.diff >> + +1: jailletc36, >> + >> PATCHES/ISSUES THAT ARE BEING WORKED >> >>*) http: Don't remove the Content-Length of zero from a HEAD response >> if >> >> >> >
Re: svn commit: r1745582 - /httpd/httpd/branches/2.4.x/STATUS
This will teach me to go back to pine... gui web clients... grrr... Final draft... On Thu, May 26, 2016 at 8:16 AM, William A Rowe Jr wrote: > Excellent, but one big issue, namespace collision. > > What about... > +#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) + +/** + * HTTPD Internal function, do not use. @see apr_cstr_casecmp instead + */ +AP_DECLARE(int) ap_cstr_casecmp(const char *s1, const char *s2); 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? On Thu, May 26, 2016 at 3:52 AM, wrote: > >> Author: jailletc36 >> Date: Thu May 26 08:52:09 2016 >> New Revision: 1745582 >> >> URL: http://svn.apache.org/viewvc?rev=1745582&view=rev >> Log: >> Proposal >> >> Modified: >> httpd/httpd/branches/2.4.x/STATUS >> >> Modified: httpd/httpd/branches/2.4.x/STATUS >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1745582&r1=1745581&r2=1745582&view=diff >> >> == >> --- httpd/httpd/branches/2.4.x/STATUS (original) >> +++ httpd/httpd/branches/2.4.x/STATUS Thu May 26 08:52:09 2016 >> @@ -188,6 +188,21 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: >> 2.4.x patch: trunk works >> +1: jailletc36, >> >> + *) core: ASCII string comparison functions optimized speed. >> + This proposal includes and renames ap_casecmpstr[n] functions >> available >> + in trunk. >> + The proposed names are the ones used in APR for the same kind of >> functions. >> + In order to avoid some new ap_ functions (which are just copies of >> what is >> + available in APR 1.6.0+), I propose to use exactly the same names >> and only >> + declare and define the functions in httpd if not available in APR. >> + The same approach has already been used for apr_time_from_msec() >> for example. >> + Also note that the implementation in APR and in httpd are slighly >> different. >> + If/when aggreed on this backport and function names in httpd, then >> trunk should >> + be upgraded accordingly. Uses of the functions could then be >> backported. >> + trunk patch: ? >> + 2.4.x patch: >> http://home.apache.org/~jailletc36/apr_cstr_casecmp.diff >> + +1: jailletc36, >> + >> PATCHES/ISSUES THAT ARE BEING WORKED >> >>*) http: Don't remove the Content-Length of zero from a HEAD response >> if >> >> >> >
Re: svn commit: r1745582 - /httpd/httpd/branches/2.4.x/STATUS
> > On Thu, May 26, 2016 at 3:52 AM, wrote: >> >>> Author: jailletc36 >>> Date: Thu May 26 08:52:09 2016 >>> New Revision: 1745582 >>> >>> URL: http://svn.apache.org/viewvc?rev=1745582&view=rev >>> Log: >>> Proposal >>> >>> Modified: >>> httpd/httpd/branches/2.4.x/STATUS >>> >>> Modified: httpd/httpd/branches/2.4.x/STATUS >>> URL: >>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1745582&r1=1745581&r2=1745582&view=diff >>> >>> == >>> --- httpd/httpd/branches/2.4.x/STATUS (original) >>> +++ httpd/httpd/branches/2.4.x/STATUS Thu May 26 08:52:09 2016 >>> @@ -188,6 +188,21 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: >>> 2.4.x patch: trunk works >>> +1: jailletc36, >>> >>> + *) core: ASCII string comparison functions optimized speed. >>> + This proposal includes and renames ap_casecmpstr[n] functions >>> available >>> + in trunk. >>> + The proposed names are the ones used in APR for the same kind of >>> functions. >>> + In order to avoid some new ap_ functions (which are just copies of >>> what is >>> + available in APR 1.6.0+), I propose to use exactly the same names >>> and only >>> + declare and define the functions in httpd if not available in APR. >>> + The same approach has already been used for apr_time_from_msec() >>> for example. >>> + Also note that the implementation in APR and in httpd are slighly >>> different. >>> + If/when aggreed on this backport and function names in httpd, then >>> trunk should >>> + be upgraded accordingly. Uses of the functions could then be >>> backported. >>> + trunk patch: ? >>> + 2.4.x patch: >>> http://home.apache.org/~jailletc36/apr_cstr_casecmp.diff >>> + +1: jailletc36, >>> + >>> PATCHES/ISSUES THAT ARE BEING WORKED >>> >>>*) http: Don't remove the Content-Length of zero from a HEAD response >>> if >>> >>> >>> >> >
Re: svn commit: r1745582 - /httpd/httpd/branches/2.4.x/STATUS
Excellent, but one big issue, namespace collision. What about... +#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) ++/**+ * Known-fast version of strcasecmp(): ASCII case-folding, POSIX compliant +AP_DECLARE(int) ap_cstr_casecmp(const char *s1, const char *s2); On Thu, May 26, 2016 at 3:52 AM, wrote: > Author: jailletc36 > Date: Thu May 26 08:52:09 2016 > New Revision: 1745582 > > URL: http://svn.apache.org/viewvc?rev=1745582&view=rev > Log: > Proposal > > Modified: > httpd/httpd/branches/2.4.x/STATUS > > Modified: httpd/httpd/branches/2.4.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1745582&r1=1745581&r2=1745582&view=diff > > == > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Thu May 26 08:52:09 2016 > @@ -188,6 +188,21 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: > 2.4.x patch: trunk works > +1: jailletc36, > > + *) core: ASCII string comparison functions optimized speed. > + This proposal includes and renames ap_casecmpstr[n] functions > available > + in trunk. > + The proposed names are the ones used in APR for the same kind of > functions. > + In order to avoid some new ap_ functions (which are just copies of > what is > + available in APR 1.6.0+), I propose to use exactly the same names > and only > + declare and define the functions in httpd if not available in APR. > + The same approach has already been used for apr_time_from_msec() for > example. > + Also note that the implementation in APR and in httpd are slighly > different. > + If/when aggreed on this backport and function names in httpd, then > trunk should > + be upgraded accordingly. Uses of the functions could then be > backported. > + trunk patch: ? > + 2.4.x patch: > http://home.apache.org/~jailletc36/apr_cstr_casecmp.diff > + +1: jailletc36, > + > PATCHES/ISSUES THAT ARE BEING WORKED > >*) http: Don't remove the Content-Length of zero from a HEAD response if > > >
