RDF Delegates provide a way to associate arbitrary XPCOM objects with an RDF resource at runtime.
The interface nsIRDFDelegateFactory should be implemented by an XPCOM service registered at the contractid
The factory will be invoked to create delegate objects from nsIRDFResource.GetDelegate()
There are three possible ownership models for resource delegates:
- Strong ownership
- The resource owns a strong reference to the delegate for as long as the resource exists. The delegate must not keep a strong reference to the resource, or the cyclical ownership will cause both objects to leak. The lifetime of the delegate may be longer than the lifetime of the resource object.
- Weak ownership
- The resource holds a weak reference to the delegate. This is useful for delegates that performs tasks but do not need to live as long as the resource they "service". The delegate may hold a strong reference to the resource.
- Dual ownership
- The delegate must implement two XPCOM objects, an inner object implementing nsIInterfaceRequestor and an outer object supplied by that interfacerequestor. The inner object must not hold a strong reference to the resource, but may hold a raw pointer. The outer object may (and should) hold a strong reference to the resource. In this model, if client code holds a reference to either the resource or the delegate, both objects are kept alive. The CreateDelegate method should return a reference to the inner object (the nsIInterfaceRequestor).
- Dual ownership
- The delegate exposes two nsISupports interfaces, an inner one implementing nsIInterfaceRequestor exposed to the RDF resource. The RDF resource getDelegate implementation forwards it's call onto that getInterface method, which in turn return calls QueryInterface on the second nsISupport interface exposed by the delegate. The second interface is breaking XPCOM ownership rules such that it doesn't delete itself once its reference count drops to 0. It merely releases all strong references to the resource. See a detailed description on http://developer.mozilla.org/docs/RDF:Delegates.
I'm not too confident that we will come up with a non-sucking explanation of dual ownership in an IDL comment. I was a bit confused by the XPCOM object term, and I'm not convinced that talking about interfaces is less confusing. I do think that the XPCOM rule breakage by the outer impl is worth noting, though.