On Thu, Jul 25, 2019 at 8:26 AM Graham Leggett <minf...@sharp.fm> wrote:
> On 25 Jul 2019, at 14:26, Nick Kew <n...@apache.org> wrote: > > > Would that be purely in C, or could it be a mix, perhaps including > scripting languages? > > Purely in C. > > Exposing APR to other languages through something like swig also sounds > useful, but that’s not my goal here. > +1 - if we correct apr-2 entirely, it is already structured as its own proper c++ implementation. We got awfully close at apr-1. Other bindings, swig or otherwise, are useful but not what you were describing, and probably have a different audience of champions/maintainers to drive it. Since it the same implementation for different programming consumers it would be a good fit right here under this PMC given enough volunteers. Very much like the Apache Logging Project (log4j, log4cxx etc.) > > First thought: harmless, but how useful is it? Do you have evidence of > a userbase who > > are insufficiently served by existing tools in a similar space? > > Yes, me. :) > :) I've spent the last month living in mingw64/msys64, all new to me since I was a unxutils fan, but that port is very lethargic, while mingw paths are a little absurd in the transitions between PS/cmd and faux-linux. And most of my real life time on Windows is now in a Windows Services for Linux Ubuntu port (similar path quirks although it is shockingly comprehensive.) Having true native ports for many of these things would be awesome... >From time to time I need to safely manipulate an URL in a shell script, or > I need to unescape something in one type of encoding and reescape it in > another, and deploying a sledgehammer scripting language to do that little > thing becomes tedious. > > As for the dbd tool, a while back I had a need to read data out of mysql > and write it to postgresql (or other way around, don’t remember) and the > native tools made this one major headache. You needed to be on the same > machine running as the same user as the database. For crying out loud, why > is this hard. > +1, this was something rbb and I bantered about. In the midst of apache-2 that really wasn't something we had even more cycles to move on. I'd be happy to port my witch.exe (deviant of bin/which) into such an effort, since it allows alt PATH searches (such as search for a .h file on the INCLUDE pathlist.) With the sed implementation donated under AL 2.0 to httpd, that would be another easy port. An APR awk port supporting utf-8 on Windows (natively Unicode) would be awesome and straightforward. >> Second question is structure. Part of APR? Alongside APR? > > > > Either within APR or your external effort: IMHO it would be excessively > bureaucratic > > to put it within the ASF but separate from APR. > > What I meant was part of the apr package, or alongside the apr package (as > apr-util is alongside the apr package). > It doesn't make much sense as part of the apr build. A [group of] package[s] with the hard dependency on apr is more sensible. Whether the apr project wants to own this, or as with our many java brethren at the ASF, it is a self-managing project is another question. Obviously there is some PMC overlap, but this is well beyond the original remit of the apr project and will attract a different audience of developers and consumers. I'd think that the APT Project (Apache Portable Tools?) would be a good community to kick off, and it should be independent and self organizing. It should follow its own versioning and release schema, since what is best practice for an API might not map 1:1 for a toolchain. Fastest track, kick off a labs demo. Then one or two paths as a community unfolds around the code, either through the incubator (great for new and less familiar contributors) or sponsored by the APR project. Either way, several mentors and build a group of committees and it should be very successful. I mentioned Windows up top, but I've had just as many headaches with small variances in toolchains between Linux, AIX, HPUX, BSD(s) and Solaris. This is a great proposal IMO.
