RE: Thinking about injection

Some other (mostly random) ideas:

5. How long did a particular step take
6. What URIs the step/pipeline accessed (for read/write)
7. What the in-scope variables/options bindings (or the entire in-scope environment?) are
8. Dynamic errors (the source of the error etc.)
9. Ability to inspect the "call stack"
10. System properties (p:system-property)

As for the ability to inject steps, I am not convinced. It sounds appealing, but also non-trivial (and likely complicated to use). Identifying where to inject steps is one thing, but then connecting the ports together (a non-trivial task in "plain" XProc) so that it all actually works is another thing. Also, in parallel/lazy/... processors it may not be always clear when (or if at all) the injected steps get executed, so there may be various interoperability surprises.

I see two main points of interception: around a step invocation and/or around an input/output port. The first is probably what most people here have in mind. Useful but at the same time potentially challenging to integrate with the existing language - if you want to execute a pipeline before/after a step, what must its signature look like and how is it all connected together?

In contrast, intercepting an input/output port is much simpler (and probably less useful because of a narrower scope), but quite easy to integrate with the language - provided there is a way to refer to an input port, any pipeline that has one input port and one output port can be used. In a way, this could be viewed as generalized p:log. The injected pipeline can just log what appears on the port, it can transform the data on the port, etc.

Regards,
Vojtech


-----Original Message-----
From: Norman Walsh [mailto:ndw@nwalsh.com] 
Sent: Tuesday, September 19, 2017 10:56 AM
To: XProc Dev
Subject: Thinking about injection

Geert Bormans <geert@gbormans.telenet.be> writes:
> The idea is to have an injection spec We agreed we need it, we 
> committed to work on it soon, but we have not specified a single bit 
> of it, so all of the following is pure speculation

Ok. I’m still trying to get my head around what needs to be specified.

Imagine I have a complicated pipeline that I think contains a bug. The goal is to have a way to enable debugging for that pipeline without changing it. And the goal of a spec would be to have an interoperable way to specify this. (Are we convinced that we need interoperability that this level?)

So. I might want to know:

1. When a particular step runs
2. What the computed values of its options are 3. What its inputs are 4. What its outputs are

Presumably it would be useful to enable these features with conditional expressions.

What more would you want?

                                        Be seeing you,
                                          norm

--
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com

Received on Thursday, 21 September 2017 08:29:48 UTC