Stas Bekman wrote: > As we have > discussed here multiple times we might not be able to release a complete > Apache 2.0 API, but only a subset of it, with further APIs released > post-mod_perl 2.0 release. Since we have lots of APIs which are untested > and undocumented, we aren't going to include those in the official API
when we discussed this, I disagreed with that idea. and I still do. http://perl.apache.org/docs/2.0/user/design/design.html#Perl_interface_to_the_Apache_API_and_Data_Structures "The goal for 2.0 is to generate the majority of xs code and provide thin wrappers where needed to make the API more Perlish. As part of this goal, nearly the entire APR and Apache API, along with their public data structures is covered from the get-go." releasing a subset of available methods is a major step backwards, taking us to the days of mp1 when APIs were added over time as users complained or developers had time - that mp2 exposes everything up front is a good thing and was part of the mp2 mantra from the start. > (read: they will be unsupported and may change) I agree with this, but it is very different than closing off parts of the API. while in some sense I understand the hesitation to expose methods that don't have tests ("untested features don't exist" is one of the XP ideals, IIRC). however, at some point we need to have faith in the code generation process and accept that autogenerated methods work sufficiently to support their release in the wild. otherwise, I see no point in autogenerating code at all. balancing robust code with rich features is often a challenge, especially in an application as complex as mod_perl. but I would rather offer up a full API that users can try out, experiment with, and offer insights into, than one that is incomplete save for APIs we (of limited resources) find the time or inclination to write tests for. I guess my own view on mod_perl as a whole goes something like this: "this is open-source and community-based software. while the development team has done (and continues to do) our best to ensure that the software is both capable and robust, there are only so many developers with so many available hours. thus, not every aspect of the software has been excercised as much as the developement team would like. if you find a bug, send a bug report and we will do our best to make it right." --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
