Re: CMPI association provider

thanks much Kirk,

I agree that it is much easier all in one type provider [given that we have
some samples to look at :)] but my project requirement is one provider per
class so i have to stick to it.....

any examples for my type of design?....badly needed help.....I am kinda
stuck :(   still researching though....

On Tue, Feb 9, 2010 at 4:09 PM, Kirk Augustin <[email protected]>wrote:

>  You can register a provider for as many classes as you want.
> So it is up to you.
> When a provider is called you know what is wanted from the provider.
> But I find it easiest to only have a single provider when there are
> associations between classes, for all the classes.
> Otherwise the providers would need some shared backend data or cross talk.
>
>  ------------------------------
> *From:* kamal jeera <[email protected]>
> *To:* Kirk Augustin <[email protected]>
> *Cc:* Karl Schopmeyer <[email protected]>; [email protected]
> *Sent:* Tue, February 9, 2010 3:43:31 PM
>
> *Subject:* Re: CMPI association provider
>
> thanks fellows......
>
> Got another question.....
>
>  Class A
> {
>  string a;
> }
> Class B
> {
>  string b;
> }
> Class AB
> {
>  A ref a1;
>  B ref b1;
> }
> Relation 1 to many [ A has many B's]
>
> now I have,
> InstanceProviderA for class A and
> InstanceProviderB for class B
> for associationproviderAB: for associators() fucntion,
> where I have instance of class A and I should return all instances of B.
> I am not sure How to do that? should I call enumrateinstances of
> instanceproviderB?
> will that possible as all three are different C files? I mean
> InstanceproviderA.c    ==> made to a.so file
> InstanceproviderB.c    ==> made to b.so file
> AssociationProviderAB.c ==> made to ab.so file.
> [my project requires those all to be different files. In otherewords one
> provider per class]
>
> I looked few examples, but all they have single provider doing both
> instance & assocation in single .c file [in that it has access to all the
> functions.]
> e.g.:
> 1)
> http://developer.novell.com/wiki/index.php/How_to_Develop_a_CIM_Provider
> 2)
> http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/pegasus/src/Providers/sample/CMPI/FilesAndDirectories/CWS_DirectoryContainsFile.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
>
> any suggestions plz....
>
> On Wed, Feb 3, 2010 at 11:27 AM, Kirk Augustin <[email protected]>wrote:
>
>>  Ah, then I can understand why there could be some choices.
>> I do not always implement associator or reference enumeration normally.
>> That is because the client can instead enumerate all of the expected
>> association and search themselves.
>> I can see how these methods could be handy if you wanted clients to be
>> able to manage the CIMON data integrety, delete instances, clean up hanging
>> ones, etc., but I find it easier to have providers take care of that
>> instead.
>> Since I don't use them in my clients, I can be more careless.
>> But it depends on what the clients you have to support expect?
>>
>>  ------------------------------
>> *From:* kamal jeera <[email protected]>
>> *To:* Karl Schopmeyer <[email protected]>; Kirk Augustin <
>> [email protected]>
>> *Cc:* [email protected]
>> *Sent:* Wed, February 3, 2010 11:03:45 AM
>> *Subject:* Re: CMPI association provider
>>
>> My bad.  Sorry to both of you karl and Kirk for misguiding/missing info.
>>
>> Kirk,
>> You are right that we need at least enumerate for a class. But if we look
>> at closely other Assocation functions they are nothing but enumerations.
>>
>>
>>    - associatorNames()
>>
>> – enumerate ObjectPaths of Instances associated with an Instance
>>
>> associators()
>> – enumerate Instances associated with an Instance
>>
>> referenceNames()
>> – enumerate the ObjectPaths of Association Instances that refer to an
>> Instance
>>
>> references()
>> – enumerate the Association Instances that refer to an Instance
>> Karl,
>>
>> I posted wrong link.  Actually I got this from Opengroup.
>> http://www.opengroup.org/onlinepubs/9699949899/toc.pdf
>> [page 55]
>>
>> Let me know what you guys think....
>>
>> thanks much!
>> Kamal
>>
>>
>> On Wed, Feb 3, 2010 at 7:44 AM, Karl Schopmeyer <[email protected]>wrote:
>>
>>> This one is easy.  The second reference (wbemsource) was a group formed
>>> several years ago but now inactive.  Use the DMTF profile specifications,
>>> they are the specifications to which we work.
>>>
>>> Karl
>>> Thanks for your message at 06:59 PM 2/2/2010, kamal jeera. Your message
>>> was:
>>>
>>> Hi folks,
>>>
>>> got some questions on CMPI association provider.  But I will stat out
>>> with basic question.
>>>
>>> I did searched on the message archive but didn't find the one I was
>>> looking for.  So here I am.
>>>
>>> OK,
>>>
>>> on this document
>>>
>>>    -
>>>    http://www.dmtf.org/apps/org/workgroup/applications/metricextensions/download.php/38074/DSP1053_1.0.0.pdf
>>>    - [note: may have to sign in before you can access above document]
>>>
>>> It says required functions as [ on page 27] remember that *CIM_MetricDefForME
>>> is an assocation class
>>> *  Associators
>>> AssociatorNames
>>> References
>>> ReferenceNames
>>> EnumerateInstances
>>> EnumerateInstanceNames
>>>
>>> on this docment
>>>
>>>    - http://www.wbemsource.org/uploads/40/3712/CMPI.pdf/
>>>
>>> It says required fucntions as [on page 32]
>>>  Associators
>>> AssociatorNames
>>> References
>>> ReferenceNames
>>>
>>> I am little bit confused which functions are must ???
>>>
>>> Thanks much.......got others questions as well but will do some more
>>> reading....
>>>
>>> Karl Schopmeyer                   Inova Development Inc.
>>> 305 Spring Creek Village, Suite 475 -  Dallas TX, 75248 USA
>>> EMAIL: [email protected]       FAX: 1-972-239-0326
>>> Phone 1-972-814-5581
>>> Skype: kschopmeyer         Skype Phone: (214) 556-5971
>>>
>>>
>>>
>>
>