> CALL FOR: Multicast/Unicast > > Called by: Nico Clasens > Total tally on this call : +2 (+3 for 1.8) > > START OF VOTING: 2004-09-22 23:00 > END OF CALL: 2004-09-27 23:00 > > YEA (4) : Michiel Meeuwissen, Andre van Toly, Pierre van > Rooden, Kees Jongenburger > > YEA, 1.8 only (1) : Jaco de Groot, Gerard van Enk > > ABSTAIN (0) : > > NAY (2) : Rob van Maris, Rob Vermeulen, Rico Jansen > > VETO (0) : > > No votes, assumed abstained (16): Eduard Witteveen, Marcel > Maatkamp, Johannes Verelst, Daniel Ockeloen, Mark Huijser, > Ernst Bunders > > > Result: > The vote did not pass. While there is small minority for > adding the code to 1.8 CVS HEAD, this is not without a number > of demands that seem to warrant a project, or at least for > teh various parties to agree on an implementation. > > There is sufficient support for moving the multicast code to > another package, but the definite name of that package (and > any class names that may need changing) is not decided yet. > Sugegstiosn are org.mmbase.notification or org.mmbase.event. > > The hack cannot be added at this moment. > It can be re-submitted after suggested changes, or made into > a project. I am very disappointed in this outcome of the HACK proposal. I thought, it had a small change to be added to 1.7, but that it didn't even make it into HEAD really astonishes me. My hack offers the same functionality as the old code (It is almost the old code). The votes against my hack mention the removal of the threadspawning. My reply on that was to replace 2 lines of the hack. I expected it to become a requirement in a positive outcome. I don't see a demand for a project. The hack does not remove or change functionality. It only adds direct-server code.
I noticed in the discussion about the renaming and packaging that people don't understand what this code does. It does not implement events or notifications. This code could feed such a subsystem, but that one is not present in MMBase. Local changes go through this code which is a de-tour, because the builder instance which initiates the change receives a call to nodeLocalChanged(). The only advantage (when you use multicast not the dummy) is that the thread which initiates the change hands over the flow to another thread. The code is only called when a storage operation has finished. Other servers with the same storage should know the change. This was the reason I called the base class MMBaseSharedStorage and why org.mmbase.storage.shared is not a bad place. An event/notification system in MMBase would only deal with local events. This code should generate a local event of a remote change. Some code in MMObjectBuilder is a start for an event system (nodeLocalChanged, nodeRemoteChanged, localObservers and remoteObservers). I am not going to do a new proposal, but the code with configurable threadspawning is in the 'speeltuin'. Nico --------------------------------------------------------------------- Logic: The art of being wrong with confidence...
