Eric van der Vlist wrote:
> What I wanted to illustrate is the more general issue coming from > the current behaviour of processors without connected outputs and I > could have given the same kind of examples with XML databases > updates, deletes and inserts.
I understand the approach. You will (probably) agree however that, whenever you try a new programming language, you need to get used to the best practices of that language. Not that we know all of them for XPL, but what I mean is that if an apparent complexity is found, it is worth considering different alternatives to evaluate whether there is really a deficiency in the language, or whether there is a deficiency in how the language is used.
And then come the big questions of how to fix the language if a real deficiency is found, and whether the fix makes the language better or worse.
So my approach is to fight changes and try to push the current approach to the limits. And your approach is to encourage changes to match what seems the natural way of doing things. In both cases, we need to push the ideas to their limits.
> My proposal to make that easier is: > > * A processor (or pipe) this isn't the null serializer is > never executed at all (its init method isn't called) if it has > no output or if none of its output is connected.
Possibly. I wouldn't want to single out a particular processor at the language level though. But this could be done at the level of the processor implementation. For the Null Serializer, nothing would have to be changed. What you would change is make the existing serializers not execute unless a particular output is read.
> * An output (named "control" or "command", "action" or > whatever) is added to each of the processors that have > currently no outputs. This output returns either an <empty/> > element or any processing information that could be useful > (for a database update, that could be a number of rows, ...).
This could just be a change to processor implementations. Note that the SQL processor behaves this way already when you read it. If you read the data output, it outputs the document based on the template specified in the configuration. If you don't connect any output however, it acts as a serializer (which is the part which you wouldn't want to see).
What I don't like with this is that you force most processors to have an output even if they really don't need one. For example, right now the serializers really don't need to return a status. They should just run. Returning a dummy result looks inelegant to me. That's what the SQL processor used to do as well, until we figured out that we could as well make its data output optional and get rid of the dummy output kludge.
> * Optional: change the name of the null serializer to something > closer to the pipe metaphor (for instance "sink" or "ground" > -more "electrical").
One issue I have with this approach is that my particular feeling has been to move away from the Null Serializer, because most use cases we've had in the past were:
<Pipeline>
<Some processor doing nothign unless its output is read> <Null Serializer reading said output so that processor executes>
This was nicely "fixed" by making sure the processor executes if it doesn't have any connected outputs. The pipeline become:
<Pipeline>
<Some processor without connected output>
Case in point, database updates: put you database update processor in a pipeline, call that pipeline, and it executes. The code looks nice and simple (see the BizDoc app for example). You don't need to think far because you know the rule that if your pipeline executes, the processors without connected outputs in it execute as well. Start adding Null Serializers all over the place, and you get more bloat. And you still have to know something: that the Null Serializer always executes.
Also, this means that every pipeline would have to have an output, otherwise they wouldn't execute, right? This would be unnecessary bloat as well, so you would instead decide that not only the Null Serializer, but also the Pipeline processor executes if it doesn't have any output (which is its current behavior).
> What I really mean is that I am convinced that the "pipe semantics" > would be much cleaner with these modifications and that, by choosing > which outputs would be connected to the sink we would control the > flow within the pipe exactly like in real pipelines or electrical > circuits.
I understand the idea / intent of pushing the pipe semantic to the limit, but I am wondering if this actually simplifies anything. As mentioned before, you do still need to have a particular "sink" processor, plus you have the "pipeline" processor. Those two processors already break the pipe idea...
> Again, I am reasoning out of the scope of this example only and > proposing an alternative to the current behaviour of the "processors > with no connected outputs" behaviour that hasn't convinced me yet > :-) ...
100% understood. Now the alternative(s) haven't convinced me yet either!
> To me, a pipe without a connected output is and should remain a dead > end!
Except... for the Null Serializer / sink, and the Pipeline processor ;-)
> Recognising it is not only more natural, but can also let us > leverage on most powerful physical effects, including the ones on > which semiconductors are based...
Of course here I am lost.
-Erik
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ orbeon-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/orbeon-user
