Stefano Mazzocchi wrote:
> 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.
Here is the point: Future concept (below) starts the process
immediately. When you get to the point where you need to know,
you wait for the result 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.
>>
>
> Yes, I know the concept.
It is very useful in situations (like above) where you need to start
an expensive operation immediately, but continue to work on other parts
of the problem domain. When you get to the point where you need the
answer, it will either have it done, or make you wait until it is done.
either way, we spend less time than simply writing everything in line.
>>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!
Concurrent programming always has its own share of issues. In this
case, we have some options. The simplest from the application
developer's perspective is guaranteed dilivery. If the request must
send an email, there will be something on the machine (most likely
an SMTP server that forwards the mail to any machine in a pool of
SMTP servers) that guarantees the request will be completed.
QoS issues mean that you can't really guarantee the timing of the
dilivery--only that it will be delivered. If you need to handle all
QoS issues within the webapp, you are going to run into alot of
headaches.
Furthermore, I don't know of any webapp that will send an email and
await a response within one HTTP request. You cannot gurantee timing
on a mail server will be quick enough. That is why there are messaging
services. If you need a request and a response in a specific amount
of time, I highly recommend JMS.
Email should be considered the "poor man's" JMS. It has no QoS
guarantees on timing--only on delivery.
> 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.
Log messages are for humans to understand what is going on with a
process. They were never meant for machine consumption. It should stay
that way.
> 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.
:) In a sense, we do that now. Technically, if we were going to really
have an input pipeline and an output pipeline, all the input generators
would be like the RequestGenerator. For XML requests, there is little
to be done. For HTTP requests, the input needs to be converted to XML.
At that point, we can figure out what we are going to do with the input
*directly*. As it stands now, we use Java code to process the input
pipeline, and XML pipelines to process the output pipeline. They are
orthagonal to each other in the sense that the content of the page
does not typically rely on the information of the request. The common
exception is a form that displays results from the last request.
> [don't know if I got all of it, though, anyway...]
That's ok, I spent 35 hours a week in school to learn all that.
>>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?
Yep!
>>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!
:) Besides, the tape deck costs more than some peoples houses (can be
upwards of $340,000 USD. (The 15 point was supposed to read 15 pounds).
BTW, ties are not allowed in rooms with these beasts. Imagine getting
a tie caught in the machine that can spin the 15 pound reels at 400 ips!
That has happened, and a bill was sent to the offender for the lost time
in the studio (blood ruins the master).
>>>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.
Keep me posted.
--
"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]
