[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Updated cluster requirements
Marcel Ruff (ruff at swand.lake.de):
> after some discussion with Heinrich, here is a
> new version.
> 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