GC API doc - Update 10

Noticed that this doc popped up on the docs.bentley.com webpage.

A lot of great tidbits on how GC works.

1. GC service mode 'exposes a "service" interface by which the separate application -- the "client" -- can create a GC model, modify an existing model, query a model for its values, and perform other operations.'

This sounds very useful. New? Hopefully, this will speed the spread of GC to other Bentley apps like ProStructures etc incl Mstn. OTOH, WCF is mentioned, so you do wonder if it is performant enough? And there is the question of what GC would use for iTwins. gRPC?

Being .NET, Microsoft-based, you do wonder if GC services could be used by non-Bentley apps like Excel... which reminds me of Rhino.Inside. I wonder what they use to tunnel inside Revit? Or Speckle? Or Omniverse Nucleus?

2. A lot of nice functionality to create smart drop downs, node outputs etc... that will require the use of VS to leverage WPF user controls etc. It would be good to have some vid tutorials on this. Even better if this could be provided as a node that can be added to a node. Constituent nodes?

3. Shadow Classes: "Whenever GC starts, or whenever the user loads a new add-in, GC uses .NET reflection to examine all the included node classes." Isn't Reflection expensive, slow?  Any way to expose the info before hand?

4. "Cheating the MVVM pattern" and the section on transactions: I think that this another performance related task that users will need to do to speed things up. It would be good to provide more info, case studies etc. Related to the Transaction Mgr's deferring, consolidating transactions functionality?

5. Getting / settting node properties: "Since this is a generic method, you must explicitly specify its resultant type. It's your responsibility to ensure that the type aligns with that property's actual declared type" When do you need to start doing this kind of thing? I presume that the Building nodes delivered with OBD have all of this kind of optimisations done. Ditto for 'helper properties' and 'shadow properties' which sounds like loading and retaining the .NET dictionary in memory. Also raises the question about when Dictionaries are not fast enough. Not sure how Item Type info is handled. Better to vonvert to Sqlite or Redis before GC has to access?

6. Parallel processing: If you are going to have to invest in explicit tinkering, then you would be tempted to manually enable parallel processing. Some examples would be good.

7. Refactoring - Game engines like Unreal provide a pathway to convert scripts into compiled C++ code. Presumably, this is old hat for .Net? Some examples would be good.

"Once you have created the base native classes for your game, you will need to reparent any prototype Blueprints to your new native classes. Once you have done this, you can start moving variables and functions from your Blueprint classes into native C++. If a variable or function in your native class is the same type and name as the Blueprint variable, you will want to change external references from the Blueprint to point to the native base classes.

... After the initial reparenting and fixups you will need to fix any lingering Blueprint compile issues and resave all Blueprints in the game. The goal is to complete a refactor with zero Blueprint warnings, so it is easier to track when new issues are added.Once things are fully working, you can then remove any CoreRedirects added during the fix-up process and clean up the ini files. "

8. ?