On 9 Oct 2009, at 04:39, Jyri Virkki wrote: > Nick Kew wrote: >> >> 3.2 Market/Requester >> mod_proxy_html has been requested by Web Stack users and >> by the originator. > > What does "and by the originator" means above?
I proposed these and other modules myself last year! >> 4.1 Details >> This is a straightforward packaging effort. The main technical >> issue >> to deal with is the dependency of mod_proxy_html on mod_xml2enc, >> which implies the latter must be available when the former is built. > > Is this a challenge which needs ARC review? I'd imagine a build > dependency takes care of it? Indeed, I think I've been guilty of "more is less" trying to work to the ARC template. >> 4.5 Interfaces > > An ARC case needs to classify all exported interfaces using the > interface taxonomy, > http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ > > >> In addition, mod_xml2enc exports an API/ABI for >> internationalisation >> support in file mod_xml2enc.h. These are expected to remain >> compatible for at least the lifetime of Apache 2.2. > >> Installed Files: >> /usr/apache2/2.2/include/mod_xml2enc.h (i18n API) > > So this is an API for customers to use when writing their own code > (custom modules, etc)? Probably an Uncommitted puiblic API? > >> /usr/apache2/2.2/libexec/mod_xml2enc.so (binary) >> /usr/apache2/2.2/libexec/amd64/mod_xml2enc.so (binary) >> /usr/apache2/2.2/libexec/sparc9/mod_xml2enc.so (binary) >> /usr/apache2/2.2/libexec/mod_proxy_html.so (binary) >> /usr/apache2/2.2/libexec/amd64/mod_proxy_html.so (binary) >> /usr/apache2/2.2/libexec/sparc9/mod_proxy_html.so (binary) > > Unless we expect customers to directly link against these, the shared > library files themselves may not be public interfaces. Indeed, I was going by the guidelines that suggested every new file should be listed under "Interfaces". > Do customers access this functionality only via configuration entries > in the config files or do they need to explicitly refer to the path to > the shared library? > >> /etc/apache2/2.2/samples-conf.d/proxy_html.conf (configuration) > > The file name is most likely Uncommitted. > > > Also interfaces, not listed yet, are the configuration file entries > supported by each of these modules. Depending on how stable these are > expected to be over time, they may be Uncommitted or Volatile. Add > entries for each to the exported interfaces table. You mean every directive for the two modules needs to be included in the ARC case (as opposed to referenced in an existing web page that documents them)? >> This project is part of the Sun Webstack, and will be packaged >> as SUNWapch22m-xml2enc and SUNWapch22m-proxy-html >> It has no impact on existing packages > > BTW the package names are also interfaces. In this case probably > Committed, unless there is an expectation to rename them. > >> 4.12 Dependencies >> This proposal depends on Apache HTTPD 2.2.x and libxml2 2.6 or >> later. >> libxml2: http://arc.opensolaris.org/caselog/PSARC/2008/032/ >> Apache HTTPD: http://arc.opensolaris.org/caselog/LSARC/2009/020/ > > Programmatic dependencies like these in an ARC case are called > Imported Interfaces. There needs to be a table which lists each > interface imported and the ARC case where it comes from (as already > listed above), the only bit missing is that each import needs to make > note of the stability of the interface being imported. This info can > be found in the case being referenced. > > > Also, add an appendix listing the full set of files being delivered in > each package (alternatively, just attach the svr4 prototype file of > each package). > > Mostly the case seems good, just needs cleanup of the formalities > noted above. Thanks. Will try & revise it today. -- Nick Kew
