> On Nov 19, 2014, at 1:22 AM, Dave Cridland <[email protected]> wrote: > > I certainly wouldn't want all delegated traffic to cause blocking.
Neither do I... I just worry about breaking the in-ordering requirement and the ramifications from doing so. Maybe the only ramification will be some protocol weenie submitting a bug report to implementor of this and like extensions. In our "iq delegation" implementation, we never block. But we're only generally only delegating stanzas for vendor-specific application where the vendor is in control of both the client and the component using the delegated namespace. An issue we did consider was IQ handling, in particular, should the server track forwarded "get"/"set" and if the component doesn't respond in a timely manner, provide the client with an appropriate "error" and, of course, don't forward the "result"/"error" the component might subsequently provide. Presently we're interceding where the component fails to provide a timely response... but I'm thinking this is a bad thing, at least in our use case. The interceding is likely to break the application which is relying on the delegation. But with more some widely used name spaces, maybe interceding is a good thing. -- Kurt
