Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>>I understand the requirement. What we need is the ability to
>>initiate asynchronous pipelines that consume information from a
>>request. I say asynchronous because in this case, we are not
>>merging the information back into the critical stream.
>>
>
> Yes. The problem being when the result of one branch is 'synchronous'
> with the result of the other branch. (say, saving something into a
> database)
Some saves to a database are not necessarily *required* to be
synchronous. The problem is not that big when you consider *when*
something needs to be done. One concurrency tool that has been
developed is the "Future". A Future is an object or value that is
declared early but used later. Typically a Future is an expensive
operation that can happen asynchronously while you are handling other
tasks. When you finally need it, the Future will block until the
value is done being calculated. In the meantime you handled a host
of other tasks simultaneously.
For instance, validation and database activity can occur simultaneously.
You will need to look up values while you are validating other values.
In the mean time, once you have an authoritative response, all you
have to do is kick off that process.
>>There has been some talk about making SAX streams concurrent (i.e.
>>an aggregation of several pipelines all running at the same time
>>to reduce time to the client). So the Multiplexer/Demultiplexer
>>idea does have some merit.
>>
>>However, let use take the abstraction up from the FET analogy.
>>
>>
>
> [snipped very interesting parallel on cocoon and audio processing]
:) glad you thought so.
>>The closest thing we have to a signal router in Cocoon is the Sitemap.
>>
>
> Agreed.
>
>
>>The sitemap does not provide a soft-wiring feature that assists in
>>creating a solution.
>>
>
> I midly disagree here: continuing on your parallel, a compiled sitemap
> is nothing different from an electrical circuit that is hardwired with
> special capabilities and then used in production.
I think you missed an important detail which I probably didn't
communicate well. A patch bay and a console follow a "waterfall"
approach to the default signal processing. This means that *visibly*
connection points from the top of the patch bay and console
automagically flow down to the bottom.
The full default signal path in a professional studio is this:
1) Patch panels in the studio map to the top row of points on the patch
bay. This is so microphones are connected to a point that can be
reassigned.
2) The top row of points is "half-normalized" to flow to the next row
down of patch points. "Half normalized" means that if you stick
a patch cable into the top row, you split the signal, but if you
stick it in the bottom row you interrupt the signal.
3) That row of patch points is mapped to flow to the channel inputs.
4) The channel inputs go to the channel preamp within the mixer.
5) The preamp output flows to an insert out (i.e. a way to insert
processing into the chain).
6) The insert out maps to the next row of patch points on the patch
bay.
7) That row of patch points are "fully-normalized" to flow to the
row of patch points below that. "Fully-normalized" means that if
you stick a patch cable into either row, you interupt normal
processing flow.
8) The row of patch points from above are mapped to the insert in
connections on the console.
9) The insert in is mapped to a fader that controls the amplitude of the
signal.
10) The fader output is mapped to the next row of patch points.
11) That row of patch points is "half" normalized to flow to the next
row of patch points.
12) the previously mentioned patch points are mapped to the tape input.
13) The tape output (i.e. recording media) is mapped to the next row
of patch points.
14) That row of patch points is mapped back into the console's track
input.
15) The track input is then mapped to a second set of insert outputs
16) those insert outputs are mapped to the patch bay (next row)
17) we have a "fully normalized" connection to the next row of patch
points.
18) those patch points are mapped back into the console's second set
of insert in points.
19) the insert in points are mapped to the track faders and pan controls
that control how that signal is mixed into the master output.
20) the master output is mapped to the patch bay
21) the patch bay is mapped to the master recording media inputs
22) the master recording media outputs are mapped to the patch bay
23) the patch bay then maps those points to the power amp.
As you can see this is a very intricate set of defaults. Basically, by
just making sure the faders are set to unity (no gain, no resistance),
and connecting a mike to the patch panel in the studio, you can start
recording music while listening to what is on tape.
Inevitably during the process of recording you will need to use some
outboard equipment. Perhaps you have a favorite compressor, or you
want to add some reverberation to the mix. Well, all the outboard
equipment is also mapped to the patch bay. All we have to do is take
a patch cable and make the connection from any point in the signal's
life to the outboard equipment and back again. All you need is two
cables.
A final mix of the recorded material typically has hundreds of patch
cables because the defaults are good for recording but not so much for
mixing.
Just as there are two phases of a cocoon app (development and release),
there are two phases of recording music (recording and mixing). At
least in this simplified version (there are also master houses,
duplication plants, etc.).
In the days before we came up with patch bays, we would physically
attach the connectors directly from one place to another. If we wanted
to change an outboard device, it required several acrobatics to get
at the back of the machine and make the connections.
This is where the sitemap sits now. Granted, an XML file is a lot
easier to deal with than the backs of hardware devices, but you
get the idea.
The "soft-wiring" I was speaking of is providing a default flow of
information that gets overridden by the developer. The sitemap becomes
a "patch-bay" if you will.
> On the other hand I see an interpreted sitemap equivalent to a
> soft-wiring, sort of a test-board where you conntect your components,
> try them out and see when they do what you want.
>
> Then you go and assemble your board (if you ever compiled VHDL or
> Verilog into circuits you know what I mean, but that's *way* down to the
> metal for the people on this list, I guess).
:/ A different point, but I see where you are going. I.e. the
difference between Xalan and XSLTC. It would be cool to provide this
for Cocoon.
>>We only have hard-wiring which means that we have
>>to explicitly state how we handle each invokation of the sitemap. Many
>>HTTP servers provide a soft-wiring that matches urls to the file system.
>>
>
> This is nothing different from the sitemap: we could easily have an
> implicity rule such as
>
> <match pattern="**">
> <read src="{1}"/>
> </match>
>
> and that would clone the default HTTP functionality, but there is
> nothing "soft" in the function of this.
The softness comes from the fact that it is easily overriden.
>>This is an easily understood default that is as fragile as your file
>>hierarchy. I don't have any thoughts on how to provide a middle of the
>>road soft-wiring for the sitemap.
>>
>
> I don't see the concept: a soft-wired sitemap would be a sitemap that is
> able to modify itself at runtime. It has been proposed (a.k.a. dynamic
> sitemap) but nobody has yet came out with a meaningful example that
> *required* that and could not be processed with a better separation of
> concerns between the pipeline components.
Here is the thing. A sitemap would be more useful to a developer if we
could easily rearrange it as necessary. But once we are done... we
can generate a class file that optimizes what we came up with. We would
use link crawling or some other methodology that would determine what
sources needed to be compiled and which ones were better left alone.
A "soft" sitemap is a developer's concern. A "hard" sitemap is a
deployment concern. Just like in the recording industry you don't by
15 point 11.5" reels of tape that are 2" thick. Those are used during
development/recording to keep all the instruments separated on tape.
What are distributed to customers are pressed CDs where the mix cannot
be altered.
>>I think that the addition of Actions can attest to that. Lets take
>>Cocoon and instead of a web application platform lets place it in the
>>light of a web services platform (all XML all the time).
>>
>
> [snipped discussion on web services platform built on top of cocoon]
>
> The more I think about it, the more I think Actions don't belong to the
> sitemap... but to be entirely honest with you, I don't have a clear view
> of where we should lead the semantics to.
>
> I see great promises in Ovidiu's work on Schecoon... but we also need a
> way to make the two things (flowmaps and sitemaps) interoperate yet
> keeping concerns separated and keep the number of contracts the smallest
> possible.
>
> And this is *not* an easy architectural task :/
Keep in mind that the Sitemap (and Cocoon as well) implement the
Processor interface. That means anything that is a signal router would
implement that interface. It can be as simple as that.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
