Specifically, POST /add_license is a request of the plugin publisher for permission to add a license for an entity.
That seems straightforward: check the number of allowed licenses plus a margin to be user friendly when something like a dead laptop happens, and either give permission for the copy to run or not. Cycle available licenses back into use over time since if you’re using the Cloud Zoo you trust Rhino to do periodic checks.
However, the docs say that
This callback MUST be idempotent, meaning that it MUST consistently return the same result given a set of arguments. This is because the callback may be called more than one time with the same arguments by the system as part of a transaction that could be retried.
I’m not sure how this is supposed to work: if the plugin publisher is required to return the same result every time the same arguments are supplied, then how do you control the number of copies in use?
Example use case:
The entity is a person who has two copies of Rhino- maybe they’re part of a happy Rhino-using family. The user only owns one copy of the plugin.
From the data supplied in the call to add a license, it doesn’t seem like the plugin publisher has solid information on how many copies of the plugin are currently in use for that particular license- they could estimate from the number of calls over time to Add License, but they’re discouraged or forbidden from acting on that information (“MUST” and the language about possible repeated calls if something fails).
Caveat: I have no hands-on experience with the cloud zoo.
The way I understand it is that these callbacks are not used when the user is requesting the use of a license, but for management of licenses in the cloud zoo (adding and removing licenses).
Each license has a unique code, so the response to add or remove a license is unique depending is that license code is valid or not. So, the request can be idempotent; you should check if the license code has been issued and is valid.
After that, the cloud zoo takes over issuing licenses to the users of the plug-in, including floating license capabilities. In other words, the cloud zoo tracks the number of copies in use, and each copy is using a unique license key.
get_license retrieves information about a license object which doesn’t contain information about a specific user/entity.
In your interpretation, would license objects almost be like a gift certificate which McNeel queries the publisher on behalf of the user to view and add_license is a user ‘redeeming’ the gift certificate?
If that were the case, then I guess the remove_license call is not for when a user is about to retire a laptop and pull the license to make it available for his new computer but for when a user wishes to remove all ability to use the license from McNeel’s records, presumably in preparation to transfer it to another account entity.
This might turn into a game of 20 questions BUT, first off.
My plugin is written in GH with a Python launch script - all wrapped up to a .YAK file using the Script Complier, how would I go about digitally signing this file? The guide above appears to only be for C++/C# plugins?
I don’t know much about the cloud zoo licensing integration beyond what Dale has written on the web page he links to, but lihe plugin created by the script compiler is a C# plugin.
I’m guessing that it would be pretty simple if you have a compiled C# plugin resembling McNeel’s my first grasshopper plugin example that just happens to be called by Python (that RHP would get signed as for a RhinoCommon Rhino plugin).