[Pipet Devel] XML descriptions for loci

[Jean-Marc Valin]

> > I suggest something like:
> > <piperplugin>
> >    <locus name = "Constant" module="General">
> >
> >          <parameter name = "constant_value" type = "ANY" />
> >          <output name = "output_constant" type = "ANY" />
> >          <comments> Locus type describing a constant value.
> </comments>
> >        </locus>
> > </piperplugin>
> >
> > If each node definition is in its own XML file, the module name can
> just be a
> > property.
> 
> This all looks great, although I'm not sure about the module thing
> just because you could have multiple levels of module organization
> within a top level category. For instance, sticking with UNIX
> examples, you could have:
> 
> unix/utilities -> for stuff like ls, grep
> unix/processes -> for process associated stuff like kill, nice

Well, the module hierarchy in this way makes sense if you are going to have many
nodes described in the same XML file, but if you have only one node, the module
is only a property. On a related topic, modules (I call them categories) in
Overflow are just a cleaner way to set up the menu. To get an instance of a
certain node, say constant, you don't need to know which category it belongs to.
It's not like a UNIX path. I see that in the same way as Matlab. You know that
the "dct" is in the signal processing toolbox, but to call it you just write
"dct", not "signal:dct".

> > Also, this is just a detail, but I suggest not to use a .xml
> > extension
> > since most of the piper files will be XML files.
> 
> I agree, I just didn't have enough brainpower to think up a good
> extension. Any ideas? random.pip? random.ppr? random.brad?

random.nod or random.cls, or random.def

> > I may be missing something, but that seems to be too compilicated
> and I don't
> > see the gain.
> 
> I guess the major gain is just that we can deconstruct the "built"
> node back into its individual components, so it could be modified and
> then "re-built." There may be better ways to accomplish this goal (or
> maybe this isn't even a good goal?). What were your thoughts on how
> 'ls -l' would look considering how the individual loci look?

It could work the same way as the current .n in Overflow: specify which nodes
you need and how to connect them. if you use a certain type, say "Constant" the
system will look in its list of available nodes, and will find the right
inputs/outputs/params. I don't like to have xml links, since it would restrict
how we can move node definitions around.

	Jean-Marc

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