## Minutes from TELECON 5 July 2001

We held the normal one (approx) Pegasus Telecon on 5 July 2001.

The following subjects were discussed.

## Modules and Queueing Proposal

We discussed the modules proposal made by Karl and Mike.

There several points in the discussion including:

Concerns that we create a model that does not encourage an environment were deadlocks could be created. Mike Day was concerned with this issue. Once we clarified that this is a tool within the CIMOM and that we do not intend to give providers free use to put things into Queues, much of this concern was relieved. Generally Mike Day notes that we need to make sure that the modules have a single input and output queue and not have free queueing capability and that we have a central means of defining the queues and of defining the setup of the queue sources and destinations

query provider interfacce.

CONCLUSIONS:: This proposal was accepted. Mike Day, Markus Meuller, Mike Brasher, and Karl Schopmeyer will work on coordinating the work between the threading and the queue so that they come together effectively.

## Tracing proposal;

Suggestions:

1. Numeric codes - This needs further defintion.

2. Use Pegasus specific names for the names ( ex. PEG_TRACE instead of TRACE) for macros. This was generally agreed. We will also put this into the programmers guide as a guideline.

CONCLUSION: We agreed that this is a good proposal and HP should go ahead. It will be implemented in the next code drop before the end of July.

## Provider Interface Discussion

We did a short review of an update by Chip of the provider interface proposal. In particular, the questions were over the creation of a separate query interface for the execQuery method, and the alternative proposal for an advanced enumerateinstances with filter capabilities. There was considerable discussion about the requirements for processing of the execute query since this is not a client method that can simply be sent on to a single provider defined by a parameter in the CIM Operation. The Dispatcher must be able to analyze the WQL query itself to be able to determine which providers are involved (it may be more than one) and either route the query on or convert it to other operations to gather the required data. Further, the query itself may involve knowing about multiple classes.

Do we need such an interface. conlusion yes. what are rules for query provider and for the provider choosing mechanism.

CONCLUSION: Have to do queries whether we do query providers or not. There is no way we can NOT provide this interface. It is a key client interface and may well be completely implemented by certain providers (ex. providers that get from a database).

CONCLUSION: We will, as we have previously stated, do Level 1 WQL only -- no joins. Note that we need to consider the possiblity of joins in the future an not create a solution that forbids them but we will not implement anything special for level 3-4 WQL today.

CONCLUSION: We will provide the query interface as defined and it will be a separate interface.

CONCLUSION: We need to look seriously at the idea of the filtered enumerated instance provider API for our providers as proposed by Roger and Mike day. This is the predicate that Mike Day talked about in the conversation last Tuesday.

CONCLUSION: Until we get provider registration we cannot effectively support query providers since there is no way to define the query provider with the provider qualifier unless we were to create another qualifier.

ACTION: General - Further expand the use case and detailed defintion of the query functions.

ACTIONS: Mike Day / Mike Brasher to work together on the establishment of the exact plans to integrate the work on

NEXT TELECON: Next Thursday. We are going to try to get a different conference facility for next week so we do not have the problem of the moderator's disappearance killing the TELECONs.

Karl