From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
People,
first of all, I apologize if I sounded somewhat harsh at time in the past two weeks. It's been a hell of a time, 8 hour-long meeting in highly political places (semantic web + jcp) and, boy, I didn't have enough time between things to realize that here I was *not* constantly under attack.
Mate, I'm from Avalon.
I have scar tissue ten meters deep, so I don't feel that much.
Yes, I know that, but, unlike avalon, this is a peaceful community and we want to keep it so.
Do we really need hotswappability?
Personally I have no need for it. The code is complex, and I am always a bit suspicious of relying on complex code. I also don't need to keep each individual server running all the time (can take them out of line one by one).
It is true that with the ability to perform horizontal load balancing, there is no much need for h13y.
However, would hotswap be useful during development of blocks? I know
that many Cocoon developers (and webapp developers) like the ability to just hit "reload my app" when the make modifications.
I also like the fact that stylesheets are reloaded when they change on disk, so I can make a stylesheet change, hit F5 to reload the page,
and see my change.
If I am going to store skins and resources inside blocks, I would like to be able to change them without restarting Cocoon.
Oh, nonono, look: this is a completely separate issue!!!
It never even crossed my mind to stop implementing autoreloading. Block hotwappability and resource autoreloading are completely different issues (and also orthogonal).
Autoreloading is a must, so much so that I would even push to have cocoon components being autoreloaded directly from java source with the compiling classloader during development time, since it would make java feel like a scripting language.... but that's something for the future and it's offtopic in this thread.
Is it worth the price to pay for the complexity?
The question is if we need to design for hotswap and/or implement it.
Autoreloading is orthogonal from hotswappability 99% of the time.
There are a few extreme cases where in order to have autoreloading you need h13y (for example, if you want to compile an XSLT stylesheet into a transformer and another block depends on this... but the sitemap's semantics currently don't allow for this anyway)
I would like us to use the design work Pier has put into the new kernel, and make sure that the Cocoon core interfaces *support* hotswap. That is, if we later on wanted to add hotswap, we should be
able to do so without changing the Cocoon core interfaces. I think we can come up with a client interface that's very easy to
use and addresses the objections to the current interface (i.e. too
ugly client code, too much responsibility on the client, etc.)
It is possible to use Pier's kernel and considers wires to be permanent. This much reduces the requirements to check if the wires are there before you use them.
This makes it possible to implement hotswappability when needed, but don't force you to use it for now.
But I don't think we have to *implement* hotswap at this moment. At least not all of it.
ok, seems that we are reaching consensus on this.
The important part is to get blocks running. Hotswap of blocks is of lower priority, and I don't want the 2.2 to be stuck in development because hotswap is so hard to implement correctly. Get the blocks running, and then we can start thinking about how to get hotswap running.
Yes, that was my feeling entirely.
Finally, when we decide to allow hotswap, I want us to start off
by realizing that we will only cover some cases when hotswap is
possible. There will always be the pathological case where hotswapping
simply isn't posible. But if we can say: "Hotswapping is possible under the following three conditions: (1) ... (2) ... (3) ...", then at least
we will have hotswap - probably for 90% of the cases - and I think
the complexity will be manageable.
Yes, I don't want to turn this into an avalon-style design about all possible pathological cases.
I'll wait for more input on this before going forward.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
