Re: Parameters redux

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> [...]
> | The advantages of this approach are that it draws on existing,
> | familiar, mechanisms rather than introducing new ones, and thus is
> | very powerful and flexible, but retains usability and transparency for
> | simple cases.
> |
> | Thoughts?
> 
> I like it. I also considered putting parameters on an input so that we'd
> be able to apply existing mechanisms; I just didn't come up with
> anything as complete as your proposal.
> 
> I'd like to find a way to simplify it just a little more. Creating a new
> kind of port, a parameter port, seems like an unfortunate bit of
> complexity.
> 
> As far as I can tell, it's only necessary so that you know where to send
> literal p:parameter elements that appear as children of the step. I
> think I'd propose that instead of having a special kind of port, we
> simply say that they go to a port named 'parameters'. It would be a
> static error to put them on a step that didn't have an input port named
> 'parameters'.

The other reason was to have automatic linking between a parameter port 
on the pipeline and parameter ports on steps, but you could do that with 
magic names as well.

I don't really like using magic names for things. I think that names 
should be something that the pipeline author chooses and that make sense 
in the context of the particular processes in the pipeline. So, for 
example, if you had a parameter port on p:http-request to set the HTTP 
headers, you could call it 'headers' rather than 'parameters'.

But I could live with it if I really had to.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Monday, 21 May 2007 15:10:18 UTC