Not a proficient app developer so feel free to edit the title to match the terminology.
What I wish to see is something like this:
I want to understand what part of these new python modules communicate with what part of the old stuff. You mention a REST API is involved, RhinoCommon is involved. Rhino Application and Zoo licensing is involved. Pythonnet module is involved. Rhino 7 is involved when using RhinoInside, Rhino3dm module, compute.Rhino3dm, etc.
How does it all work, what is the idea behind all of this?
Currently it all seems a bit scattered. Unclear.
The pythonnet module brings the .NET framework into Python (CPython, the original). Capitalizing on that the rhino.inside Python package for CPython then allows us to load Rhino as part of the Python process, after which all RhinoCommon namespaces can be imported as if they were Python modules - likewise you can import any .NET namespace as a module into Python.
For Rhino.Inside in CPython (or inside any other host process) the core of the Rhino application is loaded. This triggers the regular license checking as you would get with regular Rhino start-up.
Rhino 7 (current Rhino WIP) is where the Rhino.Inside, Compute and other technologies are built on. Rhino.Inside is what is typed above. The REST API is what is used through Compute.
The rhino3dm module is essentially an OpenNURBS wrapper module for JS and Python.
The idea is that this all increases interoperability between Rhino and other applications, ranging from other 3D/CAD packages to custom desktop applications to web applications and mobile applications.
Hijacking this topic to ask a question about the CPython implementation:
Is it possible to use scripted commands? We rely on a few scripted commands in our workflow, I suppose these are not available because there is no GUI running or am I mistaken?
If RhinoInside requires Rhino7 to be running. then what kind of web application and mobile application interoperability do you mean?
Can Rhino7 be running as a service on a server machine, and web-apps and mobile-apps to connect to that using REST. Like server-client communication with games? All calculations are happening on the server and stream the result which is then deserialized and previewed on the screen of the mobile device / browser canvas?
Scripted commands won’t work with the current implementation as there is no document when running inside of CPython. All commands are executed a document parameter and typically add/edit geometry in the document.
If Rhino7 is running on the server then how would the License be checked?
Is there a plan to implement Server License and additionally Client License?
Someone could build a Rhino server with a single license and build a web-interface that will allow others to use that server single license by multiple users. Since REST requires full payload that’s isolated from others, the server will not know if it is used by multiple users
It is scattered and unclear. There are many separate and independent technologies being created right now. We’ll start trying to figure out how to explain this once we are further along in development. The Rhino.Inside of CPython technology was just written 5 days ago and has changed dramatically in just those few days.
This was kind of my problem. Since it is all unclear I can’t figure out what I can use it for. This is why I asked for the idea and the application architecture diagram hoping to understand it better to see what I can do with it.
I saw a post about RESThopper that sounded very interesting.
For now the most useful thing seems to be rhino3dm. OpenNURBS providing support for 3dm files in other applications.
Until now (with RhinoInside) I could not see a reason to install Rhino7. I guess I’ll just do that and see what I can come up with.
Is there an idea to make a kind of ASCII-3dm format? Or as I suggested several times a zipped-XML-based-3dm project file? Perhaps this way RhinoInside will handle Rhino files easier from Python?
How about Worksession project. If you want to transfer the project you’ll have to add all files with their relative folder paths. Archiving / Extracting making sure everything is there with correct names of folders etc.
If it was a single file (XML-based zipped) it’s manifest or some settings.xml could take care of all these links. The folder structure with all sub-worksession files with all graphics settings all usertext-attributes could be shared throughout the whole project this way.
Yes, you won’t be able to use this file for multi-user work flow, but for transferring could be very handy (to say the least)
, that will be nice to play with.
