> -----Ursprüngliche Nachricht----- > Von: Joe Orton [mailto:jor...@redhat.com] > Gesendet: Dienstag, 20. Februar 2018 09:20 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS > > On Mon, Feb 19, 2018 at 08:38:05PM +0100, Ruediger Pluem wrote: > > On 02/19/2018 07:50 PM, Joe Orton wrote: > > > On Sat, Feb 17, 2018 at 02:06:20PM -0000, minf...@apache.org wrote: > > >> Author: minfrin > > >> Date: Sat Feb 17 14:06:20 2018 > > >> New Revision: 1824592 > > >> > > >> URL: http://svn.apache.org/viewvc?rev=1824592&view=rev > > >> Log: > > >> Update proposal with fix for rpluem/jorton. > > > > > > Extending dav_resource still breaks binary backards compat with > all(?) > > > consumers of this API, or am I missing something here? > > > > I don't think so. Modules that just work with pointers to structs > created by mod_dav shouldn't > > have any issues, but see below. > > Looking again, I think the way the mod_dav API is designed does make it > necessary for consumers of the API to allocate dav_resource structures. > There are a number of hooks like ->get_resource(): > > dav_error * (*get_resource)( > request_rec *r, > const char *root_dir, > const char *label, > int use_checked_in, > dav_resource **resource > ); > > ... which are implemented in repos providers which must allocate that > *resource, and hence changing sizeof(dav_resource) will break binary BC, > even if the structure was not embedded anywhere. > > > > Look at what mod_dav_svn does with the struct for an example: > > > > https://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/re > pos.c?view=markup#l80 > > > > I guess this gets us back to this _copy / _sizeof discussion we had in > another thread recently. > > Creating structures / allocating memory for them in modules is IMHO a > recipe to fail with our current > > backporting policy as we allow to extend structures at the end. > > Yup. > > In this case would moving ->acls and ->ctx to a pool note of the ->pool > field (actually is ->ctx actually used??) might work to preserve BC?
Having reviewed the above more closely and letting it sink in I just voted -1 for this backport proposal (r1824928). I think it would not be fair to let the consumers of the mod_dav API pay the price for a conflict between its API design and our backporting rules that we have created. Let's fix this up in trunk for the next major release (either in the mod_dav API directly or by providing appropriate helpers for creating / allocating / copying such structs as discussed in the other thread.) Note that this is no general -1 on the ACL extension, but on the way we add it to the existing API in 2.4.x (no -1 on the respective trunk revision). If we find another way to bring it in (e.g. as outlined above) I am fine. But we should probably let people know upfront that this API interface is subject to change in the next major release. Regards Rüdiger
