Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
<snip/>
and this solves *ALSO* the issue that was identified at the GT about "virtual pipeline components" resolving services locally or remotely (block-wise).
The current problem with VPCs is the context in which relative URIs must be resolved. We have not found a good solution for this as that depends on the point of view that is considered. What we're missing actually is the notion of "typed parameter" that would allow us to absolutize a URI at the closest point where we can determine that it is a URI and not a raw string.
In the syntax I proposed, the uri="" becomes the identifier for the service (thru relative to the block that exposes the service) and the src="" becomes the identifier for the instructions for the service (thus relative to the block that requires the service).
We already have this src="" attribute which currently is a raw string. Does this mean that we will enforce the contract on this by explicitely stating that it's a URI that will be resolved in the local context where the instruction is written?
We have to check if all of our current components use src as an URI.
I've often thought that the signature of the setup() method was wrong. The src parameter is passed as a String, the component is free to interpret it as anything it wishes. But I think this parameter was really only meant to ever be interpreted as a Source object. So instead of setup(SourceResolver resolver, Map om, String src, Parameters pars) the method should be setup(Source source, Map om, Parameters pars). That also unambiguously defines the meaning of the src attribute.
I think this solves the issue.
Mmhh... what if other parameters are also URIs?
Easy. There is no way for a sitemap to interpret it as anything but a plain string. If a component wants to interpret it as a Source it uses its SourceResolver. We'll have a special Source protocol that allows to get FileSources relative to the calling sitemap.
-- Unico
