rahul wrote: > > | Are either/both of these modules supported in both worker & prefork MPMs? > | Please document any limitations (if any). > > Aren't these limitations that may get cleared in the future if they > exists?
I don't know, you (in the role of the project "team" on this) need to find out and tell us (in the spec). > See the above. I have some reservations as to whether ARC case is the > correct place to document it. IMHO Arc cases should not act as a sink > of all transient information. rather they should document things that > should remain true during the entier life of the program as far as possible. You misunderstand the ARC review. It's not a doc describing a grand vision that'll take shape over time. An ARC case reviews a detailed technical description (ommitting implementation detail) of one very specific project. The documentation needs to describe precisely what functinality _this_ project (case) will deliver. For things which might be expected to be delivered but are not (such as e.g. 64bit support or some MPM support), it also needs to document precisely what is not delivered. If/when you decide to enhance the functionality to add support for some of the things not delivered by this case, you'll have a new case covering those when the time comes. > | That seems disjoint.. Is there an expected use case where a python > | user wants only SUNWPython-apache but not the associated module? > | Why the seemingly odd separation here? > > because there is a chance that the language library gets updated with out > the module or the other way round. With this approach, we can let user > update only those components necessary. The split means you need to be able to guaratee (one way or the other) how these remain in sync. What if the library gets updated in a way that it becomes incompatible with the corresponding module? How will you prevent that possibility? The question becomes whether it is useful enough that it's a problem worth solving (which you could solve) or just avoid it by not splitting the content (since you can alway update the package with newer module or library without updating the other, if needed). You could address it either way, taking into account how often one or the other is updated and their compatibility history and expectations etc. Either way, since it's one of those obvious questions to a reader of the doc, you'll want to have a paragraph explaining the decision. > | > 5.1. Interface Stability > | > > | > The interface stability of both of these modules are Volatile as > | > these are controlled by external organisations over which Sun has > | > no control. The specific researches regarding stability of each > | > module are captured below. > | > | As in previous cases, that's not true. The stability classification is > | not driven by who controls it, so remove that (the classification > | itself may or may not be Volatile, but provide a proper reasoning for > | the decision). > > This was what you had suggested on the previous cases. I hope I didn't ;-) One reference I can find is in this thread http://www.opensolaris.org/jive/thread.jspa?threadID=47744&tstart=105 Everything in SFW is "controlled by external organisations" (since that's the point of SFW), so that alone doesn't set the interface stability. > http://opensolaris.org/os/community/arc/caselog/2008/090/onepager/ > I have captured the reasoning correctly in the paragraphs under 5.1 (As > you had suggested for the earlier case.) The info from the communities (s.5.1.1 and 5.1.2) is great, that's just what we need. It's only the "as these are controlled by external organisations" text which is not the correct reason. > | Isn't there a documented API they'd be using? > > The answer to all the above is that I have added the documented complete > APIs as extra arc materials as documented in 5.1.1 and 5.1.2 please do > refer to these. If those APIs (the documented ones) are the available interfaces for users then that's what goes in the exported interfaces table. If it's a long list of class/method names you don't necessarily need to list them all in the table itself, leave them as addendum sections and group references to them in some logical way in the exported interface table. Keep the audience in mind when writing interface tables. A reader should gain a quick 2-minute high level understanding of what the available interfaces for interacting with this module are. (Later if they want to start writing code using them, then they can go off and read the detailed documentation.) -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
