Currently the suggested scheme treats everything as instances and object have 
methods.
This puts instancing as the responsibility of the API bindings.
I suggest changing it to the way json was designed with namespaces and methods.

For example instead for the api being:

vm = host.getVMsList()[0]
vm.getInfo()

the API should be:

vmID = host.getVMsList()[0]
api.VMsManager.getVMInfo(vmID)

And it should be up to decide how to wrap everything in objects.


The problem with the API bindings controlling the instancing is that:
1) We have to *have* and *pass* implicit api obj which is problematic to 
maintain.
   For example, you have to have the api object as a member of instance for the
   method calls to work.  This means that you can't recreate or pool API
   objects easily. You effectively need to add a "move" method to move the
   object to another API object to use it on a different host.
2) Because the objects are opaque it might be hard to know what fields of the
   instance to persist to get the same object.
3) It breaks the distinction between by-value and by-reference objects.
4) Any serious user will make it's own instance classes that conform to it's
   design and flow so they don't really add any convenience to anything apart
   for tests.
   You will create you're own VM object, and because it's in the manager scope
   it will be the same instance across all hosts. Instead of being able to pass
   the same ID to any host (as the vmID remains the same) you will have to
   create and instance object to use either before every call for simplicity
   or cache for each host for performance benefits.
5) It makes us pass a weird "__obj__" parameter to each call that symbolizes
   self and makes it hard for a user that choose to use it's own bindings to
   understand what it does.
6) It's syntactic sugar at best that adds needless limitation to how a user can
   play with the IDs and the API.

I personally think there is a reason why json-rpc defines name-spaces and
methods and forgoes instance. It's simpler (for the implementation), more
flexible, and it give the user more choice. Trying to hack that in will just
cause needless complications IMHO. IDs should are just strings no need to 
complicate them


By-Value objects should still be defined and instantiated by the bindings 
because unlike IDs we need to make sure all the fields exist and are in the 
correct type.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to