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. bon, ok j arrete la ----------------------------------------------------------- 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 ? how do I set certain aspects of the topological tree (like 1. scalability ?) (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. (it seems you implicitly do that in 'routing published messages', but stating the obvious is sometimes not bad ;)) 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 regards -- Jerome
