Bug 782891

The user of the SDK might want (we do want) to influence (not only) the __eq__ method, so It actually might be better to be able to register some other object factory method/class so people could have some control on objects creation without the need of a dirty monkey-patching. 

In other words, it would be great to be able to tell the SDK that it should create an instance of MyBetterHost (that is a descendant) of the ovirtsdk.infrastructure.brokers.Host

Setting this to urgent because this would save us much of coding which we would soon have to do.

how this is related to sdk? the thing you describing is pure client side
coding and completely not sdk prerogative, having common parameters holders
used for DOC_TYPE programming and insuring that SDK signature always stays 
backward compatible, doing what you suggesting will break entire server/client
DOC_TYPE oriented architecture.

to save monkey-patching (as you called it) for yourself, write some 
inner implementation that will create context realated parameters 
holders.

also objects not created via brokers, but from params, 
and each .create() method have __doc__ describing what parameters
should be used and how.

(In reply to comment #2)
> how this is related to sdk? the thing you describing is pure client side
> coding and completely not sdk prerogative, having common parameters holders
> used for DOC_TYPE programming and insuring that SDK signature always stays 
> backward compatible, doing what you suggesting will break entire server/client
> DOC_TYPE oriented architecture.

Say that there would be an AbstractFactory class for every broker and the client could subclass that and register it's factory object instead of some default for creating default objects. This customized object would be used to create customized instances of the brokers. I see no reason how that would break a "SDK signature". Of course the customised factory would have to respect some rules. Actually I think it would be safer than converting SDK objects to own objects and back for every action to be made.


> to save monkey-patching (as you called it) for yourself, write some 
> inner implementation that will create context realated parameters 
> holders.
As I understand (and I don't understand this statement much), you mean we should create our classes, that would be almost 1:1 to the SDK broker classes, except that they would have __eq__ and other stuff defined.


> also objects not created via brokers, but from params, 
Well, not so true:
In [13]: api.clusters.list()[0]
Out[13]: <ovirtsdk.infrastructure.brokers.Cluster at 0x2cbae50>

/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py:
class Cluster(params.Cluster, Base):


> and each .create() method have __doc__ describing what parameters
> should be used and how.
There is no .create() method in `git grep create` in the sdk git repo.

On 02/07/2012 07:52 PM, bugzilla wrote:
> Please do not reply directly to this email. All additional
> comments should be made in the comments box of this bug.
> 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=782891
> 
> --- Comment #3 from Jaroslav Henner <jhenner> 2012-02-07 12:52:03 EST ---
> (In reply to comment #2)
>> how this is related to sdk? the thing you describing is pure client side
>> coding and completely not sdk prerogative, having common parameters holders
>> used for DOC_TYPE programming and insuring that SDK signature always stays 
>> backward compatible, doing what you suggesting will break entire server/client
>> DOC_TYPE oriented architecture.
> 
> Say that there would be an AbstractFactory class for every broker and the
> client could subclass that and register it's factory object instead of some
> default for creating default objects. 

there are no 'default' objects, each resource creation using own parameters
holder, having use-case specific parameter holder is against RESTfull
application and DOC_TYPE programming principals.

> This customized object would be used to
> create customized instances of the brokers. 

you not suppose to create any instance of any object with broker, broker is only
decorator in to entity, please review SDK documentation:

http://www.ovirt.org/wiki/SDK#Creating_resource

> I see no reason how that would
> break a "SDK signature". Of course the customised factory would have to respect
> some rules. Actually I think it would be safer than converting SDK objects to
> own objects and back for every action to be made.

i didn't say "SDK signature", but  "DOC_TYPE oriented architecture", there
are few core principals that our api build on and those principals valid for
sdk as well, 

again functionality that you describing is client side implementation, or
in other words - client implementations specific use-cases and this does not
belong to sdk.

> 
> 
>> to save monkey-patching (as you called it) for yourself, write some 
>> inner implementation that will create context realated parameters 
>> holders.
> As I understand (and I don't understand this statement much), you mean we
> should create our classes, that would be almost 1:1 to the SDK broker classes,
> except that they would have __eq__ and other stuff defined.

Jaroslav, we not talking about __eq__ method, but about "Coment 1" posted by
you:

"create an instance of MyBetterHost (that is a descendant) of the
ovirtsdk.infrastructure.brokers.Host",

=> i don't mind adding __eq__, but NOT private implementations
for "MyBetterHost" ....

Further more, please do not mix different issues under same BZ

> 
> 
>> also objects not created via brokers, but from params, 
> Well, not so true:

as was mentioned above: this is only decorator for params.X

> In [13]: api.clusters.list()[0]
> Out[13]: <ovirtsdk.infrastructure.brokers.Cluster at 0x2cbae50>
> 
> /usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py:
> class Cluster(params.Cluster, Base):
> 
> 
>> and each .create() method have __doc__ describing what parameters
>> should be used and how.
> There is no .create() method in `git grep create` in the sdk git repo.

.create() implemented in sdk by collection.add(), 

- i suggest you start using some IDE, otherwise you missing core 
benefits of this sdk such as: self description, auto-completion, methods
documentations etc.

> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D

in 3.1.0.2

closing ON_QA bugs as oVirt 3.1 was released:
http://www.ovirt.org/get-ovirt/