Hi Karen. Karen Tung wrote: > Hi Jack, > > Some responses in-line. > > Jack Schwartz wrote: >> Hi Karen. >> >> Thanks for your comments. My responses are inline... >> >> On 06/12/09 13:48, Karen Tung wrote: >>> Hi Jack, >>> >>> Here are my comments: >>> >>> Overall comments: >>> >>> - Since this parser will be "the one and only" parser for all the >>> install technologies going forward, >>> I think there should be more discussion on how this change would >>> affect the existing DC, which >>> uses a different parser than the one proposed. >> I envision interfaces which will be similar to what currently exists, >> except: >> - XPaths would be used instead of paths in their current form. This >> is just a different syntax of expressing the same paths. >> - The current "one call does it all" :) setup will be replaced with >> separate calls for validation, etc. >> - The dynamic defaults setting and semantic validation would be >> layered on top of the parser. Existing defval code would have to be >> ported to use the parser interfaces to extract information and >> install new values, but I'm envisioning near 1:1 call replacements to >> what is already there. The parser interfaces listed in the spec have >> been augmented to contain the necessary hooks for this. Shouldn't be >> a big deal. (I know... famous last words...) > That's what I envision too. I am just wondering whether this kind of > information should be captured somewhere, since > it is needed for evaluating the "cost" of migrating to this new parser. I'll sneak it in somewhere :) >> >>> >>> - The "Remote Server module". From reading the document, it is not >>> clear to me how it is going to be used. A few immediate questions that >>> come to mind are: Is it going run as a server? Who starts the >>> remote server module? >> The remote server module is what the client hooks into to retrieve >> data. I called it a server as it serves data to the client. Clients >> (e.g. finalizer scripts) would run a program which calls into this >> module to retrieve data from the primary server. > I think that's the idea that I am confused about. Why we need a > remote server module? Why not make the primary > server module be able to handle remote request as well? The primary server module *does* handle remote requests but there needs to be a mechanism to get the request to it and to retrieve the data from it. The remote server module packages and sends the request to the primary server, and returns the data it gets back from it. The client calls the remote server module to handle the request so that it won't have to know about the underlying protocols. > Any request of data through a socket is remote, and will > only be read only. If you mean the data access made available to the remote client, this is true. (I didn't think there was a requirement for the remote client to be able to change the tree.)
The sockets themselves, of course, are bi-directional. > If they want to update the tree, then, they would need the "handle" > for the tree object. So, unless > they have the tree object handle, they can't write the data. Do remote clients need to update the tree? If they do, there is a way to implement that given the "handle" I'm talking about, but I don't think there's a need. > > You mentioned that the remove server module will make a copy of the tree. I didn't say that. I said that the remote server module will image the tree, not copy it. It will present the tree to the remote process in the sense that the remote process can access the data in the tree, but there will be only one copy of the tree and that will be on the server. > How will this copy of the > tree be kept up-to-date with the "original" tree maintained by the > primary server module? > If we just have 1 server, things are much simpler. See above. > >> >>> >>> Section 1.4.1, the description of DC >>> - DC also has a requirement to be able to query the data from >>> separate programs. >> Yes, that is what the remote server module is for. > I understand that the design does provide for accessing the data > remotely. However, since this > section is about the consumer's requirements, I think you should spell > it out explicitly here. OK. I'll add that both the primary consumer and finalizer scripts which are remote processes both need to access the data. >>> >>> Section 2.1, the "setup" description for Primary Server Module >>> - Why is it necessary to save a formatted copy of the data during >>> setup? I would >>> think that it is more useful to save a copy of the data after some >>> operation is performed >>> on the data. >> OK. I wasn't clear on when the operations were done. Saving isn't >> part of setup functionality, but is to be done later. I've changed >> that bullet from "setup" to "setup/save." >> > Wouldn't it be more clear to have setup and save as 2 different bullet > points, since that's 2 different functionality > that's offered. OK. > >>> >>> Section 2.4: >>> - Even with these description, it is still not clear to me how I >>> would go about doing testing using >>> these modules. Do I write a program to specify a XPATH to see >>> whether I can retrieve the elements >>> or values that I want or can I do that directly or something else? >> I changed the description to say these are standalone programs and >> went into what kind of inputs they take and how they take them. > Now, the description is better. Since these are standalone test > programs, why not just call them as such? > "Test program for primary consumer" and "Test program for remote > consumer". This raises a good point. The Primary Consumer Stand-in Module really is a test program. However, the Remote Consumer Stand-in Module can be used not only as a test program but also can be called from finalizer scripts to retrieve data. I renamed the Remote Consumer Stand-in Module to the "Remote Consumer Module" and moved it. It now appears in section 2.1 (Major Components) and has been added to the Functional Description section (5.3). I still like the name of Primary Consumer Stand-in Module though, because that's exactly what it is, a module which "stands-in" or stands in place of the primary consumer. > >>> >>> Section 5.2.1, first sentence, ".....gains access to the data tree >>> on the primary consumer by creating an object which represents the >>> data tree..." >>> - Is the remote server module going to make a copy of the tree? >> Thanks, no. I changed "represents" to "images", to infer that the >> tree isn't copied. > As mention above, how is this "copy of the tree" going to be kept > keep-to-date with the main tree? The object is *not* a copy of the tree. The object represents/images/looks-like the tree, but isn't a copy of tree, and isn't the original tree either. See above. >>> >>> Section 6.1 >>> - My understanding of the Derived Manifest project is that all the >>> fields in the manifest will >>> be derived on the client side. On the server side, only syntactic >>> validation is performed. >> I'll adjust my use case, as the server only does derived manifest >> stuff during a dry run. Removed saving of the tree for the AI server >> case. >> > In this version of the spec, it still talks about doing validation on > the server side. It also talks about the derivation is done > on the AI server side. Fixed. >> >> >> Thanks again. Updated version has been posted at: >> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_1_func_spec.2.pdf >> >> > > I got a few comments going through this updated version: > > Section 1.4.1: > - Should Dervied Manifest project's need to be able to write to the > XML data in memory > be listed as a requirement? OK. > > Section 2, second sentence, "The parser will validate the XML document > against a validation document when it starts." > - I thought the parser will not validate anything when it starts, it > just puts the XML file in memory. Thanks. Fixed. > > Section 6.2: > - This use case makes assumptions about how derived manifests are > derived. I think that's the responsibility > of the derived manifest project. Just like dynamic default setting > and semantic validation, I think it is sufficient > to say here that the derived manifest module will fill in the values. > I will change item 4, to not assume derived fields are handled one by one. That's a little too close to an assumed implementation. Revised spec will be posted after I address Ginnie and Ethan's comments. When posted it will be called: http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_1_func_spec.3.pdf Thanks, Jack > Thanks, > > --Karen > > > > > >
