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.
So, now that things have calmed down a little, I would like to start a serious discussion about the kernel that focues on what Cocoon needs and not about what is "cool" and "elegant" about the general theory of component oriented programming.
Pier and I worked together to design a system that allowed both hotswappable polymorphism, but I'm starting to wonder if this is not FS, expecially given the incredibly high costs that a hotswappable system introduces.
Now, as of polymorphism, that *is* a requirement and I think everybody agrees with me.
There are two forms of polymorphism here:
- horizontal: you have two or more blocks alongside that implement the same behavioral contract but they are different things, maintained by different communities.
- vertical: you have two or more blocks one on top of the other that are different versions of the same codebase and normally maintained by the same community.
Note how both vertical and horizontal polymorphism deal with it at the "contract implementation" level. The contract itself is subject to a similar yet decoupled versioning model, but for sake of simplicity we'll assume here that the contract is immutable at this stage.
The polymorphic hotswappability is the ability to change a block implementation at runtime, while the system is working.
What I like about the current design is that one single mechanism can work both for horizontal and vertical polymorphism.
Now, the need for polymorphism is well understood and required, while the need for hotwappability is somewhat a "plus".
There are system that perform automatic reload (many servlet containers, for example) but none of them are able to "rewire" their internal dependencies at runtime, subjected to a change in the block implementation wiring structure.
For "wire", we indicate the connection between two blocks.
In regular programming, one component connects to another component by obtaining a pointer to its instance.
In hot-swappable environments, one component connects to another by obtaining a wire to its instance.
The difference between a pointer and a wire is that (as the terms say), the obtaining component expects the pointer to be immutable (always point to the same thing), while a wire is something that might not be wired at some point in time (it could be cut by the hotswapping).
Now, this obviously forces the calling component to do checking for wireness and reconnection for every call to the wired components.
This is an expensive thing in terms of client complexity and somewhat spoils inversion of control.
There are several proposals on the table on how to deal with this (Leo listed a few) and subjected to the constrains of the java platform (which wasn't exactly designed to deal with this complexity of dynamic loading), but the real question is:
Do we really need hotswappability?
This is also a problem because Avalon doesn't have the notion of hotswappability and I'm not sure that the component loading model can be turned into one that can work in such an environment (consider that avalon loads components by String reference, while the new kernel uses pointers to interfaces as Class).
Is it worth the price to pay for the complexity?
I would like you to answer these questions before we go ahead to attack this problem which is, from all angles, I really difficult one.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
