Pegasus Meeting Minutes
TELECON, 22 June 2001
Discussion by Roger from slides shipped last night (IndicationDiscussion.pdf).
Suggestion from Mike Brasher. Create Module base class. This would include the functions like Load, unload, initialize, terminate. It can be extended to cover different types of modules. This would provide a single base for all functionality involving the manipulation of modules. Right now it would be used for the indication handlers and providers but could be extended to other types of modules in the future.
HP proposal Listeners and the design of listeners. HP Proposal is for the CIMOM to provide the listener service and then deliver the indication to the application as a provider.
The provider could at as, in effect a listener whether he subscribes or not but giving an address for that CIMOMs listener and whatever additional information is needed to route to the original provider once the Pegasus CIMOM listener receives a CIM Indication. Mike B. Noted that the base for this will be the current XML and HTTP with whatever extensions we need for the CIM Indications HTTP and XML extensions.
We discussed only the Indication delivery paths and put the subscription off until the next TELECON
ACTIONS: Mike B, Roger Telecon ASAP to define work. Definition of Modules interfaces MB.
This proposal was driven from a PDF File (Channel Connectors.pdf).
This is a proposal to extend the connectors to include two new connectors.
Roger talked about the idea of a file based authentication for local users where the server creates a local file with a key that must be read back by the user as the authentication
Using the WEB server as the HTTP server. HP made the proposal that they might want to use a WEB server like Apache as the server.
This becomes another connector type. This would be a new connector type that would accept a local connection that would pass both the HTTP and XML and would be driven from a Servlet on the WEB server. The servlet might be running as root and have to map the user to the CIMOM.
A connector will consist of 3 interfaces, authentication, transport and encoding. The connector interface encapsulates them all into a single concept. The CIMOM sees the outside world through the connector object. We must allow for multiple connectors and multiple simulatenous connections.
Some of the possible use cases:
Agreement that there is a real requirement for this functionality.
Question from M. Brasher. Does this require Java interface, etc. This function does not require the Java interface. It uses simply passes the the HTTP payload on to the CIMOM (redirecting or proxing). This assumes that the servlet processing would be sijmply on the HTTP header.
ACTIONS: Define the connector. MB and KS. The remainder of the next step of definition and the implementation are HP responsibility.
TIMEFRAME: HP, Thinking about the July release but firmly planned for August.
Mike working on it Expect first document next week. Expect working code mid July.
Will want to create an abstraction for List.
Open problem today to go through all the code to look for code that will be a problem in the threaded model.
ACTIONS: Mike Day - Put out set of programming rules to prevent more code that will break threaded model. Mike Day Working Paper on threading.
ACTION: MB/KS issue first programmers guide for Pegasus programming. This will include more than style. It will include rules for form, test, modularization, consistency of interfaces. This does not set the rules in concrete but fixes gives us a starting point for discussion.
Put up new code in Provider2 interfaces.
MB - Discussion of the concept of sequenced flow through the system (iterators vs. responders). Generally agreed that we need responders for the provider interface. It is not clear to us which is the best interface. Mike notes that the iterator interface is the cleanest for things like the repository but the responder may be for the provider. Chip notes that the responder concept allows the provider to control the return which could be important when you are locking a resource. This could even cause problems with the repository being locked for a long time. One of the possible solutions is to forbid certain queries.
When you respond from the provider it goes on the wire immediately. We need to do more research on optimizing. Note that both the Interop group and WBEMsource are involved in this. Today, we then still live with the problem that we cannot return partial.
CONCLUSIONS: Do not consider the put in a file option for the moment. We will use responders rather than interators. We will use them for the repository also.
ACTIONS:
1. CV - Document to describe the interfaces as we see them. (DUE next monday) EVERYBODY: Review the code and the document when chip sends it.
2. Responders and iterators. Chip will provide a first proposal for the interface for the responders.
TIMEFRAME: Document next Monday. Discussion next Thursday.
1. Keeping schedules through the PegasusProjectTaskListExcel File. We will be keeping the overall schedule and other information in this file. It is everybodies responsibility to review this file regularly. KS will take responsibility for keeping it up-to-date.
2. Please note changes to the CVS base in the changelog.txt. We need to be sure that every commit to CVS is accompanied with an update to the changelog file.
3. Version 1 Pegasus - Try to finish development for next telecon next week. Weekend test and release. Decide next week if we are complete and if we can release V1..
ISSUES:
1. What about interoperability testing. MB noted that we need more interoperability testing. However we have a manpower problem and need to find one or more people who will do this testing on a regular basis and report back problems. However, we also need to fix problems when they are reported.
2.What about Graphical interfaces? Mike B. Noted that we need a graphical browser. I noted that CGI Client will be extended this weekend to cover the new functions that are being incorporate and that further, we can use the SNIA browser. We do not have the manpower to develop a C++ based graphical browser without another volunteer.
ACTION: KS Update CGI client to be current with associator functions that are now added. EVERYBODY: Look for volunteer interested in writing graphical browsers.