Le lundi 31 janvier 2005 � 18:06 +0100, Erik Bruchez a �crit :
> 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.
I agree, but I also think that what beginners find shocking are
frequently signs of weak spots covering stuff that isn't as clean as the
rest of the language :-) ...
> 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.
With the approach I am proposing, I am not sure that the null serializer
should still be a processor.
> > * 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).
Exactly.
> 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.
I don't find that shocking. This output is a control over the processor.
> 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:
But then, you can't control the execution of the processor.
> <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.
But if I had control over what's going on in the pipeline, I could more
easily write a single pipeline that encapsulate several operations and
choose the one(s) I want to perform through the control outputs.
> Also, this means that every pipeline would have to have an output,
> otherwise they wouldn't execute, right?
Yes.
> 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).
Not really. A pipeline (or a part of a pipeline) could be internally
connected to the ground but that would reduce the controls that can be
applied on its execution and the behaviour would be independent of the
fact it has unconnected outputs or not.
That's pretty different from what's happening at the moment.
> > 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,
Yes.
> plus you have the "pipeline" processor. Those two
> processors already break the pipe idea...
The first one isn't really a processor and the second one doesn't break
the pipe idea! The pipeline processor acts as a container and the
circuits are the same whether they are in a single pipe or split into
several ones.
> > 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!
Too bad!
> > 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
> ;-)
No, the null serializer is the ground and the pipeline processor doesn't
break the idea.
> > 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.
I was just saying that we were close to inventing the transistor...
Never mind, if I can't convince you, I'll try to emulate this as much as
I can in my own projects!
Eric
--
Read me on XML.com.
http://www.xml.com/pub/au/74
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
-------------------------------------------------------
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
