Gareth S Bestor wrote:
To further followup on this, I think for the "generic assoc provider"
changing to a
bool AssocMatch(LHSObjectPath, RHSObjectPath)
which the developer customizes for each different association. The
potential target endpoint instances can be obtained via upcalls to the
target class(es), as we do already, but we can change the common assoc
provider methods to determine this target class automagically by
extracting the source class from the input reference objectpath, as
happens today, but then query the CIM class to determine the two
endpoint classes, rather than having to hand-code these as we do today.
Hmm. I don't see how to do this via CMPI. It's not clear how to query
the cimom about class info. Also we need the associator class name to
determine the class name of endpoints it associates. The reference
objectpath input parameter contains objectpath of one of the endpoints,
not the association class.
Perhaps the best way to continue this discussion is through some examples.
My first thought was to create a generic getTargetEndpoints() function
that would be called by each association provider. So a typical entry
pint in an association provider would look something like
CMPIStatus Associators(args)
{
CMPIEnumeration potentialEndpoints = getTargetEndPoints(args)
For endpoint in potentialEndpoints Do
if AssocMatch(sourceEndpoint, endpoint)
Add endpoint to results
}
getTargetEnpoints() signature would be something like
CMPIStatus getTargetEndpoints(CMPIBroker *, CMPIContext *,
CMPIResult *, char *className,
CMPIObjectPath *source, char
*assocClass,
char *resultClass, char *role,
char *resultRole);
where className is the name of associator class invoking the function.
Other parameters are just passed through. So some basic filtering would
be done in getTargetInstances(), e.g. ensuring assocClass (if provided)
is the subject association class (or superclass of subject association
class). Final filtering would be done in AssocMatch - which implies it
needs a few more paramenters??
The problem with this approach is I do not know how to determine the
endpoints of parameter className in getTargetEndpoints() - my point
above about not seeing how to do CIM class queries from CMPI.
Alternatively we could pass this info to the generic getTargetEnpoints()
- perhaps embedded in a structure that we define in the generic code.
Suggestions? Does this even closely resemble what you were thinking
Gareth? If not maybe some tweaking of the examples will help :-).
Thanks,
Jim
This would give us generic top-level assoc methods that are basically
class agnostic, and the programmer only needs to customize
AssocMatch(), much like the resource abstraction layer we have in the
instnace providers. Obviously, using upcalls to get *all* potential
target instances is not the most efficient, but its probbaly the
simplest. A more efficient approach would be to use a
ExecQuery(class,query) upcall - instead of EnumInstnaces(class) and
then filter - to more selectively pick out target instances, which
would translate into converting AssocMatch into a complex ExecQuery
WQL query experssion.
Thoughts...
- Gareth
Inactive hide details for Gareth S Bestor/Beaverton/IBM@IBMUSGareth S
Bestor/Beaverton/IBM@IBMUS
*Gareth S Bestor/Beaverton/IBM@IBMUS*
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
09/28/06 10:27 PM
To
Jim Fehlig <jfehlig@xxxxxxxxxx>
cc
xen-cim@xxxxxxxxxxxxxxxxxxx
Subject
Re: [Xen-cim] Memory pool question
Yup, all the association provider code *should* be mostly cookie
cutter, with only changing a few globals necessary to customize to
specific applications, namely:
/
/* Info about the left and right hand side classes of this association. */
static char * _ASSOCCLASS = "Xen_RunningOS";/
/
static char * _LHSCLASSNAME = "Xen_ComputerSystem";
static char * _LHSPROPERTYNAME = "Dependent";/
/
static char * _RHSCLASSNAME = "Xen_OperatingSystem";
static char * _RHSPROPERTYNAME = "Antecedent";/
/
/* Key property of the LHS and RHS objects that must match to make the
association. */
static char * _LHSKEYNAME = "Name";
static char * _RHSKEYNAME = "CSName";/
However, some of the assoc providers dont use this 'new' version with
the LHS and RHS keyname check. Typically, when the assoc was always
1:1 it was just a matter of enumerating the target class, as opposed
to looking for specific matching instances, the simpler version w/o
LHSKEYNAME and RHSKEYNAME was employed.
Although these template can (and have!) simplified making new assoc
providers, both the assoc provider templates and the base instance
provider templates do end up re-using a lot of common code across a
lot of providers. So figuring out a good way to dump some/most/all of
this code into shared libs could I think greatly reduce the footprint
of these providers. Also, although the cookie cutter approach also
made it easy for me to mock up a lot of providers quickly, and after a
handful of refinements I was pretty satisfied with the template and
stopped tweaking them, actually putting all the common code *in one
place* (rather than trying to maintain 30-odd copies of it from
various points in time) will make future maintenance and retro-fitting
bug fixes/changes a LOT easier in the long run. So definitely, there
is a LOT more that can be done here to really optimize and extract the
common code from all the providers and package it in a better way. I'd
LOVE to discuss ideas (alas, not tomrrow morning 'cause I cant make it :-)
- Gareth
Inactive hide details for Jim Fehlig <jfehlig@xxxxxxxxxx>Jim Fehlig
<jfehlig@xxxxxxxxxx>
*Jim Fehlig
<jfehlig@xxxxxxxxxx>*
Sent by:
xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
09/28/06 04:25 PM
To
"Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx>
cc
xen-cim@xxxxxxxxxxxxxxxxxxx
Subject
Re: [Xen-cim] Memory pool question
Subrahmanian, Raj wrote:
> Jim,
>
>> Are you working on Xen_Memory, Xen_MemoryPool and all of the
>> related associations? I'm about done with it :-/. Pretty much
>> a repeat of the Processor stuff I finished a while back. In
>> fact, many of the associations have common code that needs to
>> be abstracted out. It would have significant impact on lines
>> of code :-).
>>
>> In addition I have another version of the memory stuff (and
>> all other providers that touch Xen) for the new C bindings.
>>
>
> Have you checked in your changes into the repository?
> When I checked the repo last, it was still in the earlier state.
>
Just checked it in. MemoryPool and all of its associations now exist.
> Have you started working on abstracting out the common code?
>
No. This is probably the next task. Perhaps we can discuss some issues
related to this on tomorrow's call.
Jim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxxx
__http://lists.xensource.com/xen-cim_
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
Home