[Pipet Devel] Re: [Pipet Devel] Re: Ideas for network distributed objects

[Jean-Marc Valin]

"J.W. Bizzaro" a écrit :

> > OK, I'll try to summerize the way XML is used in Overflow with an example:
> >
> > <?xml version="1.0"?>
> > <Document>
> >
> > A document is a file and can contain many networks (it's the equivalent of a .c)
> 
> Then this is something like Loci's 'workspace' or 'workflow diagram', or
> Jarl's 'dataflow structure'.

Something I forgot to say about documents... if this document is in the
VFLOW_PATH, then the whole document can be used as a node in another document.

> 
> >   <Network type="subnet" name="MAIN">
> >
> > A network if the C equivalent of a function. Each document must contain a MAIN
> > network.

BTW, the network type can be three things: "subnet", "iterator" or
"threadedIterator". The "threadedIterator" is very experimental, so I will not
talk about it. A "subnet" is the C equivalent of a function, while the
"iterator" is the equivalent (not exact) of a loop. Actually an iterator is the
equivalent of a function that looks like

void foo(...)
{
   while(condition)
   {
      do something
   }
}

> >
> >     <Node name="node1" type="Constant" x="-294.000000" y="101.000000">
> >       <Parameter name="VALUE" type="subnet_param" value="IN"/>
> >     </Node>
> >
> > This is a node definition. The name is arbitrary,
> 
> The name is akin to Loci's identification number, which is really a URI to the
> XML representation of the node.
> 
> > while the type corresponds to an Overflow node class.
> 
> Great, this is just like Loci's locus types/classes.
> 

Just to make sure everyone understand, the definition is the equivalent of a
function call, not a function prototype/implementation.

> > x and y are for the GUI.
> 
> I think for VSH we should have the GUI store that information.  If we are to
> have more than one interface available for VSH, x and y will not always be
> relevant.  This is what we were going to do with Loci.
> 

I didn't like that either. It was just simpler to have everything in one file
(since this is the only info that was GUI-dependent)

> >  The parameters have to correspond to what the node expects.
> 
> This is like a mime-type for link I/O?  This is also something Loci was going
> to define.

I'm not sure what you're talking about...

> 
> >     <Node name="node5" type="MAIN_LOOP" x="-26.000000" y="108.000000">
> >       <Parameter name="FRAME_SIZE" type="int" value="256"/>
> >     </Node>
> >     <Node name="node2" type="ExecStream" x="-165.000000" y="98.000000">
> >       <Parameter name="COMMAND" type="string" value="cat"/>
> >     </Node>
> >     <Node name="node6" type="Constant" x="-162.000000" y="186.000000">
> >       <Parameter name="VALUE" type="string" value="frames"/>
> >     </Node>
> 
> I'm not sure what you mean by value=256, cat, or frames.
> 

Here's the C equivalent:

void foo(int aNumber);

main()
{
   foo(256);
}

This would translate to:

<Node name="node1" type="foo">
   <Parameter name="aNumber" type="int" value="256"/>
</Node>

Also about parameters... Here is a macro that appears on top of each file that
implements a node:

NODE_INFO(FIR,"Signal:DSP", "INPUT:FILTER", "OUTPUT",
"LENGTH:CONTINUOUS:NONCAUSAL")

Here, FIR is the name of the class (the node's "type"), "Signal:DSP" is just a
classification for the menus, "INPUT" and "FILTER" are the names of the inputs
and "OUTPUT" is the name of the output. This node accepts 3 parameters
(arguments): LENGTH, CONTINUOUS and NONCAUSAL.

When the node is loaded (its library is dynamically linked), a function puts
that info in a node "database", which the GUI uses to know what node are
available (and takes what arguments).

> >     <Link from="node8" output="OUTPUT" to="node9" input="STREAM"/>
> >
> > Links define which node is connected to which. Input and output names need to be
> > defined since nodes can have more than one input/output.
> 
> Excellent, just like Loci.  Although Loci embedded <link> (what Loci calls
> <input> and <output> 'connectors') in with the node information.  This is how
> Loci defines a node (loci == node, although 'locus' is singular):
> 
>   <loci type='document' >
>     <widget>file_select</widget>
>     <input xml:link='simple'  href='baselocus.xml' >
>     </input>
>     <output xml:link='simple'  href='workspace1/viewer1.xml' >
>     </output>
>   </loci>

We used to have links as a property of the nodes (before we switched to XML).
The reason we changed is that is that a Link in the GUI is an actual object, so
it was just simpler.

> (Brad, shouldn't we also have locus 'id=' in here?)
> 
> In this example, when we say 'type=', we mean the same thing you do with
> 'type='.  But our type 'document' is a node that stores data: a file.  It's
> not where Loci sets up a network.  What Overflow calls 'document', Loci calls
> 'workspace'.
> 
> <widget> is the name of the interface component to be used.  We're working on
> using more XML here, and the 'widget' representation in XML can be located
> anywhere on the Internet.
> 
> <input> and <output> define the links (connectors) for this particular node.
> href points to the XML representation of the node it is connected to.
> xml:link is from an XML document linking tool that Brad has been using.
> 
> Loci also gives the node an ID (not shown above) that is the location/URI of
> the node's XML representation.  Here the GUI of Loci requests that a node
> called 'viewer1' gets linked to a node called 'document1':
> 
>   <connect>
>     <input id='workspace1/viewer1.xml' >
>     </input>
>     <output id='workspace1/document1.xml' >
>     </output>
>   </connect>
> 
> Other information related to a node (e.g., library URI and version number) can
> be kept between <loci> and </loci>
> 
> >     <NetOutput name="OUTPUT" node="node9" terminal="OUTPUT"/>
> >
> > NetOutput means which node (and which output of that node) will be used as the
> > output of the whole network. The same applies to NetInput and NetCondition.
> 
> What is the actual output?  The screen, a file?  Or is this something the user
> defines?

The output is what getOutput() returns... you can do whatever you like with it.
batchflow (text mode tool) writes it to stdout, vflow (the GUI tool) writes it
in a subwindow. If you want to save it in a file, all you need to do is to have
the last node be a "Save" node. ...or the last node can be a soundcard output...
In most cases, the output of the MAIN network is a nil object.

> 
> >   </Network>
> >   <Parameter name="IN" type="string" value="/data/ntt/french/*/*"/>
> 
> In this case, the whole 'document' gets a 'parameter' tag?
> 
> When I first came across Overflow (when you posted the announcement on
> gnotices), I noted to Brad how remarkably similar some of its features are to
> Loci's.  This is particularly true for the XML representation of a network.
> 
> This is something GMS (which uses no XML) needs to implement as well.  And
> since Overflow and Loci are so similar, we should choose one definition.  Can
> you comment on what you like or dislike about Loci's use of XML for network
> representation?  Let's hammer this out right away.

I'm not that much a fan of XML... The only reason I used it was that it saved me
so much time (instead of writing a parser myself). So Anything that does the job
is OK for me.

	Jean-Marc

-- 
Jean-Marc Valin
Universite de Sherbrooke - Genie Electrique
valj01 at gel.usherb.ca