Hi Jack, > Hi Sarah. > > On 06/17/09 08:44, Sarah Jelinek wrote: >> Hi Jack, >> >> I cannot attend today's meeting. I do have some thoughts about this >> topic which I have included below. > Bummer that you couldn't attend the meeting. Thanks for making your > thoughts heard. My replies are inline. >> >>> Hi everyone. >>> >>> I am calling a meeting tomorrow regarding AI manifest organization. >>> We need to discuss the structure of the files again in a context of >>> scalability and a compelling user experience. >>> >>> I request that those people explicitly addressed attend, others are >>> most welcome as well. >>> >>> Meeting logistics: >>> 14:00 - 16:00 PST (2 hours, just in case) >>> Toll Free Dial In Number: (866)545-5227 >>> Int'l Access/Caller Paid Dial In Number: (215)446-3648 >>> ACCESS CODE: 7385082 >>> >>> The main issue is that the functional spec defines two or three >>> files, in two different formats, and that the user will probably >>> have to edit them to set up an installation. How to simplify this >>> from the user point of view and make this a more compelling >>> experience? How to set the files up to make it as easy for a >>> first-time one-system user as for an admin of a large lab with many >>> different groups of systems? >>> >>> We have many factors to consider. >>> - One hard constraint: The System Configuration (SC) manifest must >>> be a DTD to fit as an enhanced SMF profile. >>> - We can't rely on existence of GUI tools to set up the files. >>> - We don't want to have the contents of the SC manifest specified in >>> another schema format because we don't want to make users learn two >>> different formats for specifying the same data. >> If we have a hard constraint that the SC manifest be a DTD, and we >> say we don't want the contents of the SC manifest to be in a >> different schema format, seems like conflicting requirements. >> Although, I don't know how hard a requirement the statement above is. > Today I realized that, under the covers, we can pull apart a manifest > which has all three sections (including an SC manifest portion) before > validating any of the sections, so we can place all three sections in > one file.
Ok, sounds good. >> >> I think it is desirable, as much as possible, to hide the details >> from users with regard to the SC manifest contents. Although, >> anything we do to manage this means we track any changes in the SMF >> enhanced profiles schema. Someone has to track the changes I suppose, >> just a point to think about. > We discussed today the usefulness of a tool not just for SMF setup but > for everything, and we will recommend that as a future enhancement. > We also discussed a tool which could export a running system's SMF > configuration to a file. Should such a tool be developed, the file > structuring will be ready for it. Being that we can't count on a tool > for now, we are focused on the files and their relationships for now. >> >> I think the real issue is not the schema definition that is >> different, imo, but that if the users have to manually edit and >> provide individual SMF enhanced profiles for every SC entry, it could >> be cumbersome. What is the intended delivery mechanism for any SC >> manifests users want for installation? I mean is this something users >> must provide or is provided by other groups who own the piece of SC >> functionality? >> >> If it is part of the standard OpenSolaris service definitions, >> couldn't we provide a way for users to override the settings that are >> defined in these enhanced profiles via our schema? > The SMF profile (except for a couple of header lines specific to DTDs) > is XML like the rest of the manifest. The main difference is that it > is validated via a DTD vs a RelaxNG schema. > > Being that the SMF profiles are XML just as the rest of the AI > manifest is, it would be all the same to the user to modify the SMF > profile directly rather than do it in another part of the manifest. ok, fair enough. >>> - RelaxNG schema is much easier to read and work with than DTDs. >>> >>> Agenda: >>> >>> Let's start with a few minutes (really) to discuss broadening the >>> problem statement and set the tone. I'll suggest the following to >>> start things: >>> >>> "AI manifest structure and organization should be easy to use and >>> understand, and scale to a wide variety of installation environments." >> >> It wasn't clear to me in yesterdays discussion why we would have 2 >> manifests in the simple case? I thought the 'standard' manifest would >> be only one manifest, with no sysmap pointer(the pointer would be >> null). The SC stuff could be embedded in the standard AI manifest >> and something users could modify if they wanted. The AI manifest is >> then embedded in the sysmap manifest. Is this not the case? > The terminology isn't quite accurate, but after the meeting today, it > changed again anyway. It is simpler now. One manifest with three > sections: criteria, installation, configuration. Either or both of > the latter two sections can be populated with data, or a pointer to a > file containing the data. Excellent! This sounds like a good compromise. >> >> I think the proposal you have currently works very well in the >> 'scaling to a wide variety of systems'. > Thanks. We kept the option of having pointers to files to those last > two sections for scalability. >> >> One thing we have talked about is making it easier for users to use >> AI out of the box. To setup services and understand what the client >> behavior will be. Is simply making the manifest(s) easier to edit a >> possibility to ease the learning curve? Do we know of an XML editor >> that might be useful for this? > We thought that having many files and incomplete examples would make > it harder for users to learn. > > We will be proposing working examples for a single, self-contained > manifest; and a manifest with pointers to files containing the > installation and configuration sections. These will be fully > commented, and list all fields to serve as an example. They will also > work - out of the box. Users can start with these and tweek them as > needed. This sounds really good. Thank you for taking the time to work on the user experience. sarah ***** > > I'll be posting meeting minutes tomorrow and a revised functional spec > as soon as I can. > > Thanks, > Jack > > >> >> >> thanks, >> sarah >> **** >> >> >>> >>> Then we'll move into discussing what our options are to solving this >>> problem. >>> >>> Thanks, >>> Jack >>> >>> P.S. I'd like to leverage what we already have, at: >>> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.6.pdf >>> >>> >>> >> >
