perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> Yes - the metadataIdRef of the 'subject' element should be used here. 
> We have called this 'filter-chaining' in the past, but I guess it is 
> really more of a 'function' step. 'function-chaining'?

Definitely we have to name those two types of chaining (then we could 
securely use those names in documentation). I propose:

- base-chaining (or merge-chaining)
- function-chaining

What do you thing?


> Now, this might sound silly - but the part I always struggle with is 
> what 'order' things should be chained:
>
> data -> cron -> owamp
>         or
> data -> owamp -> cron


I prefer:

data (trigger) -> cron -> owamp


Here, owamp test is the target and main action defined in the request. 
Cron section contains details how to manage owamp test.

Let's consider example with built-in transformation (I assume 
transformation details will be in a separate metadata):

data (trigger) -> cron -> transformation-> owamp


> It probably doesn't matter that much. But, it would be good to have a 
> clear reason that can give guidance across multiple service/message 
> definitions. For example, I am hitting a similar issue with bwctl:
>
> data -> bwctl-scheduling -> iperf
>         or
> data -> iperf -> bwctl-scheduling

iperf section is for me the target action and scheduling section defines 
how to call iperf test. The second example is right for me.


this pattern came to my mind (I hope it's clear :)  :

[data trigger] ->[transformation | constraints | instructions]* 
->[target action]


Roman

> (This is for a new version of the bwctl schema. The current one 
> basically has a single metadata that includes iperf and bwctl options. 
> But the next version of bwctl will support other throughput tools such 
> as nuttcp and thrulay so I was trying to factor out the bwctl specific 
> things.)
>
> jeff