From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
On 26 Mar 2004, at 11:57, Leo Sutic wrote:(which you
Think about TCP/IP. You have guaranteed delivery of packetsdon't have with UDP). Completely guaranteed? No. Achopped-off networkcable is not something that the protocol can handle. But still very useful.
The TCP/IP is a good example...
To use the same parallel, when I open a TCP connection I am guaranteed
that I'm going to get a Socket object (to use Java) I can use. But the
platform doesn't guarantee me that its InputStream or OutputStream are
going to be valid forever, they might throw IOExceptions, and the socket itself can be in a connected or disconnected status (you're never guaranteed).
You go usually until you don't hit an IOException on the streams (or isConnected() returns true), but then you'll have (somehow) to handle that state change which you don't control...
Wirings between blocks behave in the same way, you go until one of the
methods you call doesn't return an exception, or until the wiring is available (err, you can check on that),
Actually, you can't.
There's no guarantee that the block isn't going to be swapped out between the checking call and the next method call.
So there's absolutely no point in making the checking call.
There's even no guarantee that the block won't be swapped out ***while it is executing a method***.
Now that's starting to become dangerous.
Why? If a request fails because I reloaded the XSLT Transformer block, well, I'm ready to loose that request... Cocoon is a servlet, at the end of the day, and I'd rather loose XSLT translation for 1/2 a second while I reload the XALAN block, than wait 10 minutes while I reload the JVM, as I can't reload XSLT because every single Pipeline in my sitemap is locking on it, and (of course) I will never ever be able to reload it until the traffic on my website goes down to ZERO...
Dude, don't get upset, I'm not thinking about the holy grail here, I _DO_NOT_WANT_ to write another Avalon, I want Cocoon to have a container tailored EXACTLY for its own requirements, being a servlet and all...
Let's not forget that we work on HTTP connections, and that at any given point in time, those can be disconnected, time out, or your network admin can unplug the cable...
What's the difference between that, and loosing the connection for a second with a component? Thing, that (by the way) will _NEVER_ happen automagically, but only when the administrator decides that it's time to reload a block instance?
Instead, the difference between having to shut down a VM because you need to reload a component (and loosing ALL your requests, but also all your continuations, sessions, you name it), and unwiring a component (and loosing ONLY the requests that were using that component), is for Cocoon quite a friggin' advantage.
That's ALL _IMVHO_, I don't know what others think, but we mustn't forget that our container needs to solve one very very very specific problem, the Cocoon problem...
Pier
smime.p7s
Description: S/MIME cryptographic signature
