Hi Sundar, My comments/questions...
General question: Why is the primary objective of this project include design and implement two example mechanisms? Is this for design research? Section 2e: I would think we would want to have some performance requirements to ensure our choices with regard to design are the right ones. I think part of what you outlined in 2f are performance requirements. Section 2c: I would like to see a list of the functionality that you plan to provide with regard to observability. Even if these functional pieces are phased in, I would like to have a list to know what we are going to provide. The statements in this section say 'may be provided'. Also, what does this mean: > Explicitly, we will not be transporting observability data as that > task will belong to future observability work. Section 3: > > User interface interaction with the transport mechanism are minimal. > Server user interface is limited to starting and stopping the service. > Observability data will be provided to the user through observability > tools provided by later external work. Client user interface is > limited to the SMF service which controls the start and stop of > auto-install. Is there any user interaction or user interface that allows the users to configure their server to support their environment needs? In section 4: Deliverables: I am a little confused by the use of the word 'should' when describing the functionality provided for the major components of the AI transport. Is there decision on what will be provided that we can clearly identify? Also, do we need to include on the server the ability to provide dynamic content to clients? Not required now for any known Caiman project, but maybe for the future? 6. Use cases: > Server Goals - > > 1. Receives requests for data files > 2. Sends requested data files > 3. Determines the AI manifest for each specific client Is it really a server goal for the transport mechanism to determine the AI manifest for the clients? It is part of the AI processing, but not a part of this project, is it? General note: I don't think we should mention specifically that the client requests the solaris.zlib file. Perhaps we say something like client requests image file. Because we may not have a solaris.zlib specifically for the client to request if we change the layout of the images. So, why are we including under Use Cases, the transport of the NBP, when we don't have control of this at this point in time? Does the transport mechanism redesign include this? Are there things we plan to do with regard to re-design or new features in this area? How is use case #2 different from use case #1? So, a few general questions: 1. The outcome of the redesign work, past the functional spec, is to provide a set of modules and interfaces that abstract the data transport mechanism from client to server, right? 2. The choice of transport mechanism and application that does the transporting, e.g. webserver/http, is part of this project as well? thanks, sarah ***** > Hi, > > The functional specifications for AI transport (Web Server > redesign) is available at > http://wikis.sun.com/display/OSOLInstall/Web+Server+Redesign+Functional+Specification. > > Please review the specs and provide your feedback by 06/15/09 > > Thanks, > Sundar > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
