Hi Ethan, A few responses in line.
Ethan Quach wrote: >> >> Here are my comments: >> >> Section 1.3: >> - Shouldn't there be a dependency on the parser to allow data from >> the manifest to be modifiable? > > I should probably note that possibility. I mentioned > below that on the server, a base manifest will be validated > when a user adds one to an install service on the server, > but I don't really describe how; its not yet clear to me > whether we want the parser to do anything special for this. > The parser doesn't need to do anything special, but I think you should spell out the fact that the parser must make all the data available for modification. Depending on the requirement, one can implement the parser so that data is read-only. But looking at this design, I think you want the whole tree representing the XML to be read-write accessible. > >> >> Section 5.3 >> - Will this new smf service for deriving the XML file end when it has >> completed >> it's work? Will it output a "new" manifest with the derived values to >> be consumed by the auto-install smf service? > > yes and yes. Thanks for clarifying. I suppose this info will go into the spec as well? > >> Before it create this "new" manifest, >> will it also validated the manifest syntactically, >> semantically...etc.. So, the auto-install >> smf service can assume that the given manifest is valid and not need >> to do >> duplicate work? > > It could do the same type of validation as would have > been done on the server for a complete manifest (I think > right now that's just syntactical validation.) before > coming "online". Actually, my question is about which SMF method will do the validation? The "new" smf method that does the derivation or the auto-install SMF method? The reason I ask is that the derived-manifest SMF method should probably do the validation, because not having the correct derived manifest should more more accurately reported by the derived-manifest SMF method. But if the auto-install method will do it again, then, it is doing duplicate work. So, I am wondering whether there's thinking to avoid the duplicate check. > >> - Also, since this smf service is separate from the the auto-install >> smf service, >> how would the output/error from this service be reported? Will it be >> a separate >> log file from the auto-install service? > > Its a separate log file. > As Alok pointed out, we would have different log files for AI clients then. >> >> Section 6: >> - All the uses cases are not really use cases. To me, they are more >> like pseudo-code >> describing the code path of different things that can happen when >> derived manifests >> are used. > > Okay. I think we need to add some end to end use case > scenarios like, "user wants target disk to install on to be > derived." Is this what you are thinking? > Yes, I am thinking about end-to-end use cases describing the user's experience. From the user's point of view, he doesn't need to know what code gets executed and how. He is more interested in what he needs to do from the user's point of view to get his job done. Also, if whatever he does succeeds, what he will see, and how he will be able to find out. If his input fails, what error messages he will see, and how he would find out what is wrong. Things like that. As Ginnie noted in her response to this comment, having the pseudo-code is good for developers to make sure we cover all the possible code paths, but I personally think that use-cases should talk about what the user's experience in using the software. Thanks, --Karen
