The interest is to allow several languages access to a base dynamic shared object (i.e. DLL) given an API that can be used across each language.
Some languages provide their own methods for process threads. If the API supports an abstract class that can be used across each languages, then this is the kind of standardization that is less complex. The interface is the same instead of the complexity of many different implementation across each language. There is also further complexity when a specific language actually is actually supported by its hosts environment, which is common with virtual machines. These VMs work best when the threads are controlled by the VM instead of by the guest environment, the DLL in this case. There are some advanced topics about this I'll avoid here. When you run the viewer as a standalone executable, it is its own host and guest. The viewer doesn't need to be a standalone executable, as the base code for it could support an API as noted above. This essentially turns what was the viewer into a DLL. The communication layer in-n-out of the blackbox, like between the DLL and any specific language, is the g-objects. I think some were confused by that with the mention of other languages. This is beyond the proof-of-concept stage. To pick out a use case, I'd point out the need for a multi-threaded API that works for each language. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
