Berin Loritsch wrote:
>
> 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.
Unless you have logical dependencies on it.
> 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.
Yes, I know the concept.
> 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.
I'm not worried about these cases, Berin, but about the cases when you
*need* to way for the result of one branch to execute the other.
For example: I want to send email. One branch serializes to the mail
server, the other serializes back to me. But if the server is down, or
misconfigured, or I'm not allowed to post, or.... I want to know it
right there!
Sure, errors could be saved in logs, but the user doens't have a way to
access those logs (nor should). he/she just wants immediate feedback.
Well, we could implement this with transformers and WriteableSources
(which is the way I would do it right now) and use branching pipelines
for 'asynchronous' things.... but my concern is that if we implement
branching pipelines (even if elegant) users might use them in the wrong
place because (i've seen this happening myself) people tend to reuse
components in weird configurations rather than write their own 10 lines
of java code.
This is dangerous in the long run.
[skipped long description of how complex is something so apparently
simple as 'recording variations or air pressure' :)]
[don't know if I got all of it, though, anyway...]
> 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.
Ok, now I got it.
You are asking for a 'base sitemap', something that you should use to
start with and should be flexible enough, yet useful, to make you work
right away.
Did I get it right?
> > 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.
Yes, totally. The awesome thing would be to do have a tool that does
this 'assembling' and should
1) compile all XML into compiledXML to increase performance
2) prevalidate the XML that needs to be validated
3) compile the XSTL stylesheets into translets
4) compile the XSP into generators
5) compile the sitemaps into code
6) package the whole thing
7) deploy on top of Cocoon
so you get:
1) easy installation
2) best-possible performance
3) non-modificability of things in production (useful to avoid the
lost-update problem when people fix on production and forget to make
fixes back on the original source)
I think this goes along with my proposed cocoon web apps concept of
modularization of cocoon web applications.
> > 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.
Exactly.
> A "soft" sitemap is a developer's concern. A "hard" sitemap is a
> deployment concern.
Precisely.
> 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.
Perfect parallel! right on, brother!
> >>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.
I wasn't talking about implementation but about design. But Ovidiu got
my point, so I'll continue there.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
