[asdf-devel] patch for component-relative-pathname

[james anderson]

On 2010-02-19, at 21:47 , Faré wrote:

> On 19 February 2010 06:49, james anderson <james.anderson at setf.de>  
> wrote:
>> this problem has been in asdf "forever".
>> i have always just patched it locally, but as i've now thrown a few
>> things in the net which other folks should be able to build, i
>> suggested the correction.
>>
> Thanks for the correction.
>
>> it might make sense to consider an entirely different protocol for
>> constructing the component pathnames.
>> in order to better predict the result, asdf-x tries to turn the
>> protocol around and do it from the top down, rather always on-demand
>> from the bottom up. the bottom-up protocol has to recurse to the root
>> anyway in order to construct the intended pathnames.
>>
> The problem with an entirely different protocol is compatibility.
> A change would break things for some people. Who? Where? I don't know.
> It would break things for me, and I'm willing to deal with it,

i'm curious what would break if the effect of the protocol change was  
that component pathname always actually returned pathnames which  
conformed to any reasonable spec for which the present implementation  
could possibly have been written.
what kinds of things can one expect from it except relative pathname  
extension (modulo '..') and absolute rerooting.
the rfcs on uri resolution are detailed enough that it's a known world.
that the present implementation does different things in different  
runtimes is enough to mark anything which depended on its behavior as  
non-portable and deprecated.

does any other issue which come besides the consequence of modifying  
the graph to chance module/system constituency. in which case, upon  
reflection, one would need to automatically re-root the effected  
components anyway.

> but would it break things for someone, somewhere who will be pissed  
> off?
> Maybe, maybe not. Who's to take the risk?

maybe asdf needs an rfc process.

>
> If you're into designing better protocols for better tools, why not  
> jump
> on the XCVB bandwagon where you don't have anyone to be  
> incompatible with,
> and plenty of room to do something useful instead of language  
> lawyering?

because the core problem which asdf should be able to solve is really  
a rather simple one, as things go, which it, itself should be made to  
solve better.