Hugues Jerome wrote: > Marcel Ruff ([EMAIL PROTECTED]): > > >>Hi >> >>after some discussion with Heinrich, here is a >>new version. >> >> http://www.xmlblaster.org/xmlBlaster/doc/requirements/cluster.html >> >>comments (in any langauge) are welcome >> > > konichiwa minnasan, daijobu desu ka.
Michele, please translate. > bon, ok j arrete la Merci. > > ----------------------------------------------------------- > My two cents regarding this feature (note that I do not know > the internals of xmlBlaster, so I may be sometimes wrong) > > *) You speak about discovery and lookup, but not about the internal > configuration. I do understand the lazy login concept to build a tree, > but some other concepts are missing : how do I setup my node as a master, > do you want this caracteristic to be static or not ? The internal message <key oid='__sys__cluster.node.master:heron'> has a list of message domains which define 'heron' as a master. Such a __sys__ message with other domains may be re-published by a client or an administrator or an domainManagerBusinessObject which reconfigures the master setup dynamically. see http://www.xmlblaster.org/xmlBlaster/doc/requirements/cluster.html (the example section at the very bottom). > how do I set > certain aspects of the topological tree (like 1. scalability ?) You are right this is missing. I will address it. > > (by static I mean that cannot be changed during runtime) > > *) Regarding the features : > > if you look at 'connections between xmlblaster instances', my > understanding is that if a node do not have the requested message, > then it subscribes directly to the master node. this is too restrictive > and prevent building a tree structure .. depending how you read 'the' > > take diagramm 1., bilbo will directly subscribes to heron(labelled as > master), bypassing frodo (labelled as slave) > > hence 'the master' is not precise enough. Yes, we need some configuration possibility, thanks for pointing on it! > > (it seems you implicitly do that in 'routing published messages', but > stating the obvious is sometimes not bad ;)) Yes again. > > this loop back to the first point, and requires the precise definition > of 'master' and 'slave' in your context, the way such a relation is > defined and handled during runtime > (or at least comment the examples, they seem to provide some useful > information I cannot read: __sys__cluster.node.master) > > case 1. and 3. are similar to some multicasting problems, this may > be a key to a solution Could you explain further please? thanks for your valuable feedback mer lernt jo immer dazue (- Michele please translate.) regards, Marcel -- Marcel Ruff mailto:[EMAIL PROTECTED] http://www.lake.de/home/lake/swand/ http://www.xmlBlaster.org
