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