[Dev] XML parsing functionality in the GUI

[jb at integralive.org]

> Just keep in mind here that we're only talking about a difference
between >one programming language and another.  As far as I'm concerned
there's >nothing inherently "better" about doing it in Max's javascript
vs. >programming an external that calls to libIntegra.  If we can avoid
>duplicating effort then it's a better solution.

Yes, don't worry, I understood that to be the case. The only reason why
I'm suggesting that you stick with the javascript for now is that I don't
want the library development to slow GUI development down because you're
waiting for certain functionality.

>
> With regard to what I said previously about the translation path: XML ->
OSC -> Max
>
> We should remember that the "OSC -> Max" part would be pretty trivial,
so don't let that necessarily stop us from using it if it seems like a
good idea.
>
> As Jamie said, only the "master" will have to deal with XML.  I would
actually argue however that the DSP engine should be the master.
>

I think the library should be designed in such a way that it is fairly
straightforward to have either the GUI or the engine as master. However,
the more I think about it, having the engine as master does seem sensible
for the reasons you state below.

> In that case, the GUI's job is to dynamically send "create", "destroy",
and "connect" messages to the DSP engine for instantiating and
> connecting modules.  However, the DSP engine is the one actually doing
the saving and loading of the current "state" into the XML file.  In
that case, the GUI would simply sit there as a "dumb terminal", and the
DSP engine would be responsible for telling it what to do.
>
> This is how PureData works, and it seems to be a successful paradigm.
One argument is that the DSP will sometimes need to function without a
GUI, so being able to load XML by itself is necessary, while the
converse isn't true.
>

That's why I proposed the 'standalone' mode
(http://www.integralive.org/dokuwiki/doku.php/lib:comms), right at the
bottom :-)

Actually it was pd -nogui that made me think of this mode.

> One alternative we might consider is a 3rd-process application, some
sort of "Integra manager", that sits in between the GUI and DSP to deal
with module-level"connections, and saving/loading/database stuff.  It
could keep its own internal representation of the module network, and be
responsible for ensuring that all GUI and engine instances are in the
correct state.
>
> In any case, if both the GUI and DSP engine are designed to act as
"slaves", then we can embed this "master" application into either side
as we see fit.  Writing it as a separate process might make for easier
development in the meantime.
>
> In short:
>
>     DSP <-osc-> Manager(XML) <-osc-> GUI
>                     |
>                 Db Server
>
>
> Where "Manager" either runs on its own, or is embedded into DSP or GUI,
possibly both (as long as only one is enabled).  At least implementing
this OSC layer should allow us to move around this "manager" layer more
easily if we want to.
>
>

I absolutely agree with all of this. With the scenario above, we could
have many nodes attached to the Manager, all implemented 'inside'
different DSP environments, which is really something Integra strives for.

The only thing that I would add is that nodes registering with the Integra
Manager (service?), should still 'contain' a client that links to the 
Integra lib. I think this is the best design for providing
functionality for module instantiation, which as a minimum, means the
ability to parse module definitions (XML), and the mechanism to translate
these into environment-native form, and to receive commands via OSC. Doing
it this way (using the lib in each node including the server), makes the
system more homogeneous/maintainable/scalable I think.

Great stuff!

Jamie