Hi Jack, I cannot attend today's meeting. I do have some thoughts about this topic which I have included below.
> 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. 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. 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? > > - 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? I think the proposal you have currently works very well in the 'scaling to a wide variety of systems'. 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? 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 > > >
