[kepler-dev] Global access of a value among all workflow actors?

[Bertram Ludaescher]

Just to add to Norbert's comment on "collection-oriented workflows"
(Tim, Shawn, and myself currently working on this): the basic idea is
to avoid "control-flow induced" branching in workflows (which BTW also
often/always? breaks SDF as a possible MoC) in various ways. For
example, one can often linearize a workflow and have just "one
pipeline" by letting actors "pass through" information; an actor can
then still decide locally what info to work on. 

This approach can be used to inject new parameter values in the main
data stream, then let downstream actors pick up the new params (if
they recognize them as being parameter update requests)

Bertram

>>> On Thu, 2 Mar 2006 13:57:33 -0800 (PST)
>>> Norbert Podhorszki <npodhorszki at ucdavis.edu> wrote: 
NP> 
NP> Hi Nandita,
NP> some days ago I was also struggling with such needs (configuration 
NP> determined at beginning influences all subworkflows; logging; 
NP> (implicit) control flow).
NP> 
NP> My own answer for myself was:
NP> This would be a different (second) mechanism for communication among 
NP> actors, which is not presented by the graphics. I think, Ptolemy and 
NP> Kepler, and any other graphical design tool can kill itself in two 
NP> different ways:
NP>   1. When people feel the tool too limited, developers try to add 
NP> workarounds. This results in the extensive use of workarounds, so the 
NP> original becomes meaningless: why to use cumbersome graphics if we can 
NP> solve it easier?
NP> 
NP>   2. Developers resist. Tool users then go for textual tools, where 
NP> expression is stronger.
NP> I know one example, the P-GRADE graphical parallel programming 
NP> environment, from my previous institute, is limited by graphics to express 
NP> all message-passing possibilities. -> People still use MPI to write 
NP> parallel programs.
NP> 
NP> 
>> From other viewpoint:
NP> 
NP> 1. 'Global' works as long as you are located in a shared-space 
NP> environment, practically on one PC. Whenever, Kepler/Ptolemy will support 
NP> execution in distributed environments, a support for global notion could 
NP> introduce a bigger mess than that extra dozens of connections.
NP> 
NP> 2. As far as I know, there is no graphical tool for shared-space concept. 
NP> Because, how could you represent the mess, what happens in a shared-memory 
NP> application, graphically?
NP> 
NP> 
NP> I would like to think about rather graphical solutions,
NP>   e.g. layered views, (bring to front/send to back a'la Powerpoint)
NP>   e.g. colors/styles for connections (I would distinguish in my workflows 
NP> data flow/control flow/configuration info/logging info)
NP> 
NP> Tim McPhillips and Bertram Ludaescher are working on the "collection 
NP> oriented" dataflow concept, which can reduce the number of connections on 
NP> the screen. Such an approach may you help, or not.
NP> 
NP> Best regards
NP> Norbert
NP> -- 
NP> 
NP>       Norbert Podhorszki
NP>     ------------------------------------
NP>       University of California, Davis
NP>       Department of Computer Science
NP>       1 Shields Ave, 2236 Kemper Hall
NP>       Davis, CA 95616
NP>       (530) 754-8188
NP>       pnorbert at cs.ucdavis.edu
NP>       ----------------------------------
NP> 
NP> On Thu, 2 Mar 2006, Nandita Mangal wrote:
NP> 
>> 
>> Hi there,
>> 
>> Is there anyway/ possible implementaion, where given an output generated
>> from an actor, can be stored in the worfklow Parameter/ other location?.
>> And later on that value be used by mulitple actors on the same canvas?.
>> The need for this is required to avoid messy connections b/w main and
>> multiple other actors (accessing the output generated from the main
>> actor) Hence a global value / global token that can be edited and
>> accessed by a given workflow.
>> 
>> Thanks,
>> Chien-Yi
>> Nandita Mangal.
>> 
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> 
NP> 
NP> _______________________________________________
NP> Kepler-dev mailing list
NP> Kepler-dev at ecoinformatics.org
NP> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev