Hi Sergey,
The negation is here so the server can know which namespaces the
component wants and what it musts delegate. If we don't do that, the
wanted namespaces need to be written directly in the configuration of
the server, and changed each time the component change them.
I don't think that it's necessary to do a full namespaces negotiation
process in a case of admin mode because:
* it makes process more complex without any need of that because
component won't get more than admin allowed anyway
I don't see the complexity here. Component won't get more, but they need
to know what they can do, and server need to know what they want to do.
* server will have to refuse stanzas with these namespaces when
component is down by some reason, so the namespace lease is permanent
and does not need any negotiation
That's a good point, actually the bahaviour is not specified when
component is down (actually the server would manage the stanza, which is
not desirable). The issue is actually the same in client mode.
So you suggest to block the namespace (send an unavailable error) when
component is down in admin mode, which is indeed an option, but what
ould you do in client mode ?
* i think it makes it easier to implement at least just admin mode both
on component and server side
Yes that's the idea, and it's actually written in implementation notes #1.
The <IQ/> negociation is not complicated, but the behaviour when
component is offline is not specified and that's an issue. Your
suggestion make sense, but what would you do in client mode ? Let the
normal behaviour when no entity manage a namespace ? That would mean a
different behaviour in admin and client mode, that's it ?
We still need to inform component of which namespaces delegations have
been granted and we can do it with a simple message stanza containing
the namespaces.
If we choose to specify namespaces in configuration, that's an option
indeed. But first it's important to specify what to do when component is
down, thank you for pointing this.
Cheers
Goffi
