Hi Sarah, I have a few responses, see below.
-Keith Sarah Jelinek wrote: > 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? The purpose of implementing 2 mechanisms is to demonstrate the modularity. But, since you brought it up, I wonder if the statement of intent to design & implement an alternate mechanism falls outside the functional spec? > > 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. Performance of the transport mechanism is inherently related to the number of clients requesting data. I think that these 2 sections should be combined - is there any specific requirements missing from section 2f that you feel should be added? > > 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. This means that transmission of observability data is outside the responsibilities of the transport redesign project. For example, if, for observability purposes, the client should be transmitting which package it is currently installing to a remote location, transportation of that data will be handled independently of any work done for this project. To be more clear, the "transport mechanism" for this project is concerned with transmission of .zlib files, configuration files, and manifest files only. Other data, including pkgs, and client status, are currently outside the scope of this project. > > 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? This should be reworded. While it is not the transport mechanism's responsibility to directly determine the file, it is responsible for "getting" the file. For example, if you go to a search engine and search for "OpenSolaris", it is not the web server's responsibility to run the search query; however, the server IS responsible for invoking the search, and returning the results once the search completes. > > 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? I don't necessarily define use cases to be bounded by the scope of a project. I think they can and should extend beyond scoped boundaries if it helps supply context. I've noticed scoping comments coming up about use cases from several projects though, so I wonder if I should be shifting my thoughts on this. > > How is use case #2 different from use case #1? Fundamentally they are the same and could be combined, changing references to "solaris[misc].zlib" to "image file" as you suggest above. > > 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? Yes, as mentioned above, the desired outcome is to refactor such that transport mechanism is modular, and to implement 2 different transport mechanism modules. > > 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 > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
