My earlier mails did not go thru, resending these. | > | > | 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). | These modules do not have limitations on the above. This is just FYI | > 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 entire 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 (omitting | implementation detail) of one very specific project. The documentation | needs to describe precisely what functionality _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. Architectural Review is a misnomer if the above is its mandate. But the ARC goals and what it involves are contrary to (or at the very least not concerned with) what you have suggested.
Goals http://opensolaris.org/os/community/arc/ What ARC involves http://opensolaris.org/os/community/arc/arc-faq/arc-review-overview/ More over, in How to succeed http://opensolaris.org/os/community/arc/arc-faq/arc-review-advice/ "Make sure you are presenting clear, concise architecturally sound interfaces that are written properly." "A sound definition defines the interface, the arguments, the results and describes what the interface does, and need not describe the implementation" It clearly states that it is interested in the interfaces between components rather than the implementation details. The things like 64 bit support for the present, and MPMs currently supported are implementation artifacts that do not have any thing to do with either architecture or the interface (Unless the non-support is due to an architectural limitation. - Since the above modules does not have any such architectural limitations, I had chosen not to include it in the ARC case.) | > | 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 guarantee (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. | Well, the same thing applies to supplying apache and the modules. what if apache is upgraded but modules are not? I think it is useful to split the library component and the native component also because it is treated as two independent components by the upstream project and are delivered into two different locations. I will add it this to the ARC case. | > | > 5.1. Interface Stability | > | > | > | > The interface stability of both of these modules are Volatile as | > | > these are controlled by external organizations 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 organizations" (since that's | the point of SFW), so that alone doesn't set the interface stability. I will remove that sentence, (I had taken that verbatim from the previous arc case on jk/fcgid/security.) | | > 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 | organizations" text which is not the correct reason. ok. | > | 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. This is what is done currently, except that I added them as supporting materials. It is a very long list of classes and methods, and I was not able to attach them to the post due to the size restriction. | 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.) rahul
