I haven't received any replies to this email. Was the original email
too long? :)
If no feedback is received, we'll assume that preserving backward
compatibility with the existing OpenWBEM/Pegasus Python provider
interface is less important, and we'll feel more free to change the
interface to optimize for use under CMPI.
Does anyone have feedback?
Bart Whiteley wrote:
> Bart Whiteley wrote:
>> Shashi Uli wrote:
>>> Hi, Are there any plans to make a pywbem providers work with SFCB as
>>> well ?
>> Funny you should ask. I hope to have it working in a couple of
>> weeks. Who wants to help? It's currently in the OMC project
>> repository . This is because it uses SWIG and will support Ruby
>> (and potentially other languages) as well as Python.
>>  http://omc.svn.sourceforge.net/viewvc/omc/cmpi-bindings/
> Time for an update on this project, and a discussion on the state of
> the Python provider interface in general. If you are currently
> writing Python providers, or anticipate doing so in the future, please
> read and comment.
> I've got instance and method providers working, and association
> providers mostly working. I've been using the test suite for python
> providers under pywbem/pyprovifc/test. My goal thus far has been to
> be able to take existing, unmodified Python providers that run under
> the OpenWBEM or Pegasus Python provider adapters, and run them under
> SFCB through a CMPI/Python provider.
> The Python/PyWBEM provider interface under CMPI consists of the
> following stack:
> SFCB -> libpyCmpiProvider.so -> pycmpi_provider.py ->
> pywbem/cim_provider.py -> <python provider module>
> This is a CMPI provider that uses SWIG  to wrap CMPI objects
> (CMPIInstance, CMPIObjectPath, CMPIArray, CMPIArgs, CMPIResult, ...)
> for use with Python (or other languages -- currently Ruby is also in
> progress). To SFCB, this looks like any other CMPI provider. It uses
> the "Generic MI Factory Functions"  so that the "MI Name" is passed
> in, and can in turn be passed to the Python layers to determine which
> Python provider module to load. This CMPI provider initializes the
> Python interpreter, imports pycmpi_provider.py, and then each MIFT
> function wraps or converts its arguments, and then calls a
> corresponding method in pycmpi_provider.py.
> This module contains methods that closely resemble the CMPI MI
> function tables for each type of CMPI provider. These methods convert
> the arguments passed in from swig-wrapped CMPI objects, to PyWBEM
> objects. Then the corresponding method is called in
> This hasn't changed. It is the same Python module that is called by
> the OpenWBEM and Pegasus Python provider adapters. This module
> contains the logic that loads individual Python provider modules, and
> drives the Python provider interface.
> The CMPI Python provider adapter is different from the OpenWBEM and
> Pegasus Python provider adapter in some ways. One is the existence of
> pycmpi_provider.py. The OpenWBEM and Pegasus provider managers both
> load pywbem/cim_provider.py directly. I chose to insert a new layer
> of Python (pycmpi_provider.py) under CMPI for a few reasons:
> - I would prefer to convert objects from CMPI to PyWBEM in Python
> rather than C.
> - The C layer -- at least the part that isn't generated by SWIG -- is
> pretty minimal (thanks to SWIG).
> - Multiple Python provider interfaces could be implemented by
> providing different glue layers between libpyCmpiProvider.so and the
> Python provider modules.
> - The C layer isn't dependent upon PyWBEM.
> Now, there are some things we need to discuss. The current PyWBEM
> provider interface makes heavy use of the schema information available
> from CIM classes at run time. There is a history behind this. The
> native OpenWBEM C++ provider interface hands a CIM class to the
> provider for each provider operation. So, when we implemented the
> PyWBEM provider interface (first under OpenWBEM), we took advantage or
> the CIM classes with little performance penalty. Pegasus doesn't pass
> CIM classes down as part of its provider interface, so the Pegasus
> Python provider adapter retrieves the CIM classes via a GetClass
> "up-call" to the CIMOM. This causes a performance penalty (possibly
> not very significant), especially with out-of-process providers. With
> CMPI, the situation gets worse. There is no representation of CIM
> classes in CMPI, and there is no GetClass "up-call" available to CMPI
> providers. The pycmpi_provider.py module compensates for this by
> performing a GetClass client call with the PyWBEM CIM client
> (pywbem.WBEMConnection). A CIM class cache is employed to minimize
> the performance impact. In order to make this work, a patch to SFCB
> is needed. Hopefully the patch will be included in future versions of
> SFCB. The patch  allows SFCB to listen for HTTP connections on a
> unix socket, and use unix socket "peer credential" authentication to
> authenticate local client connections without a username/password.
> This situation gets a little worse with Association providers. The
> AssocClass parameter to Associators and AssociatorNames, and the
> ResultClass parameter to References and ReferenceNames is allowed to
> be NULL by DSP200 . However, OpenWBEM and Pegasus always fill in
> this parameter (since the CIMOM knows what it should be for each
> association provider that is called) for calls to the providers (even
> CMPI providers), even if the client specified NULL for these
> parameters. SFCB doesn't do this, and as a result the
> pycmpi_provider.py module has no way of knowing which CIM class to
> retrieve if the client doesn't specify an AssocClass or ResultClass.
> This means that current PyWBEM providers under SFCB cannot function if
> a client doesn't specify an AssocClass for Associator[Name]s, or a
> ResultClass for Reference[Name]s. I'm not sure how serious this is in
> the real world. I suspect that those parameters are usually provided
> by the client in most applications. However, it does complicate the
> test suite code and test tools (YAWN ). I have PyWBEM association
> providers mostly working under CMPI when the client provides the
> AssocClass or ResultClass parameter. There are still a couple of bugs
> that I'm tracking down.
> So, where do we go from here?
> I was hoping to preserve compatibility with the PyWBEM provider
> interface that exists today under OpenWBEM and Pegasus. I'm not sure
> if this snag with Association providers is severe enough to make this
> goal unachievable. Again, the association providers will work, but
> only if a client specifies the AssocClass or ResultClass parameter.
> After completing this initial iteration of the PyWBEM/CMPI provider
> interface that is compatible with the existing PyWBEM provider
> interface under OpenWBEM and Pegasus, I intended to make a new
> interface that doesn't require an "up-call" to retrieve CIM classes.
> This should make the providers run faster. The good news is that this
> should be able to happen with only minor changes to the provider
> interface. Existing PyWBEM providers should require only minor
> modifications to be ported to this new interface. For those of you
> currently writing Python providers, I hope this won't discourage you.
> The backwards compatible interface that I have mostly working today
> should provide a migration path.
> I'd like some feedback on the above brain dump. Also, some other
> questions in general:
> - Do people even want to use PyWBEM objects in the provider interface,
> or would they prefer to use something that more closely resembles CMPI
> (or even the SWIG-wrapped CMPI objects directly)? We chose to build
> the Python provider interface around PyWBEM initially for a few
> reasons, that I think are all still valid:
> -- We were familiar with the PyWBEM CIM objects, and liked how they
> -- We wanted to be able to share code between clients and providers.
> -- We wanted to be able to use pywbem.WBEMConnection within
> providers, and be able to pass the results from client calls directly
> back up to the CIMOM.
> - How many Python providers are in existence today that would require
> a minor port?
> - Are there any areas of the current PyWBEM provider interface that
> people are unhappy with, or would like to see improved while we have
> this opportunity to make changes to the interface?
> I look forward to your comments.
>  http://www.swig.org/
>  CMPI v2 specification, page 31
>  http://pywbem.wiki.sourceforge.net/YAWN