[Dev] gui instance host question

[Stephen Sinclair]

On Wed, Jul 9, 2008 at 8:02 AM, Henrik Frisk <mail at henrikfrisk.com> wrote:
> Jamie Bullock <jb at integralive.org> wrote:
>> I would also add that although it isn't possible to have a IH-less
>> bridge (see previous email), it is perfectly feasible to have multiple
>> bridges per IH (although this isn't implemented yet). This could be
>> useful if one of your bridges ran its instantiation functions across the
>> network stack. The SuperCollider bridge will work like this (it will tap
>> into SCServer's OSC messaging protocol). In this case it might be
>> desirable to have the integra_sc3_bridge loaded into the same IH as say
>> integra_pd_bridge if your collection is spread across those two apps.
>>
> I think we should discuss this more. I think it would be useful to be
> able to have multiple bridges per IH. We also have a slight terminology
> problem (perhaps the confusion in this thread is evidence of that?) with
> the IH proxy that doesn't actually host any instances, only a
> bridge. What about letting the bridge encompass the proxy functionality?
> This is obviously purely conceptual, nothing in the implementation
> really has to change.
>
> Thanks Stephen for shedding some light on our confusions!

Ha, I wish I had done it earlier.. :)

Instead I have been looking at the code and trying to follow it
closely to figure out how it is following the Integra papers I have
read.  In most cases it's okay, but I finally found that certain
concepts were just not clear in my mind, so I had to ask.

I guess in a way I've always been a little confused by the appearance
of the instance_host in the GUI part of that diagram.  I remember
being surprised by it at first, thinking that all communication with
libIntegra would take place over OSC.  Then seeing that there is some
OSC, but the GUI will still have direct contact with libIntegra... now
that it's been explained to me that OSC is intended as simply another
channel for communicating with libIntegra this all makes more sense.
I'll think of OSC being used more like an RPC mechanism from now on,
and consider it on the same level as a C API, or even an XML-based web
service style of API.

So, since it's *optional* to use OSC for communicating with
libIntegra, do you think at this moment it is more worthwhile to use
it as is, or to work on the C API?  I have successfully been writing a
bridge (integra_xpcom_bridge) for a XULrunner-based application.
(Hence the need for the C++-related fix I recently pushed.)  This may
play out to be a good idea for the GUI, but it is also just to help me
understand how interaction with libIntegra is supposed to work.
However I've already got OSC working in XUL, so I could equally use
this.  I think all concepts clarified through this work can also be
applied to the Max GUI.

I am thinking now that if I just implement a JavaScript API to
libIntegra, which uses either XPCOM or OSC for transport, the rest of
the XUL application can ignore how it actually works.  We could then
also later implement an XMLHttpRequest-based back-end for the exact
same JavaScript API and end up with a web-style application that runs
the same locally or through the browser.

One thing stalling this is figuring out which functions should be
exposed through JavaScript.  This has mostly been mysterious to me due
to the lack of C API, but now I understand that it is the current OSC
handlers that I should be looking at exposing through JS instead.  (In
the process, there will have to be a C API, so two birds with one
stone.)


Steve