[Dev] gui instance host question

[Jamie Bullock]

On Wed, 2008-07-09 at 18:33 -0400, Stephen Sinclair wrote:

> 
> 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.

Hehe... I think you've found some 'documentation bugs' ;-)

... seriously though, the Wiki is intended to be a workspace for
exploring current and future ideas. There is probably some stuff on
there that is either out-of-date, or will never happen. (maybe I should
make that clear on the Wiki front page?)

The doxygen documentation OTOH is supposed to be the absolute truth (!),
so if you find inconsistencies or ambiguities, please file a bug report
against it (or just let us know). 

<snip>
> 
> 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.

Wow, cool, someone's actually going to *use* libIntgera. Not only that,
they're actually writing a new bridge. This is really exciting stuff for
us!

> (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 think it depends what you really want in your app and how soon you
need it. If you'd really like a C API to work with then I think we
should hike that up the priority list. We have a release due on the
19th, and it might be possible to squeeze this in to the task list for
that.

> 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. 

Would that be *instead* of using the C API?

>  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.

This is very much along the lines we have been thinking. In particular
Henrik is working on offline web app for working with Integra Bundles.

You might want to look at our idea for a pluggable frontend/backend
architecture for the lib:

http://www.integralive.org/dokuwiki/doku.php/lib:reorganisation#pluggable_architecture

This is a 'hidden' page on the wiki, where we're dumping ideas for
refactoring. Some of them have already been implemented.

> 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.)

I'll start looking at the basic API today, so people at least know what
will be exposed in the future. I keep in you in the loop so you can give
your input etc.

best,

-j

-- 
www.postlude.co.uk
http://www.linkedin.com/in/jamiebullock