Karl Fogel wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>
>>It sounds to me like what's broken is the idea that we can validly stick the
>>"@PEG" back on to a path or URL again after parsing and canonicalising it.
>>
>>Do you think we can get rid of all the code that relies on that, and
>>deprecate the functions that do it and any functions that currently
>>take "<canonical path or URL>@PEG" as input? Once we've parsed the
>>syntax, keep the results separate. That sounds like the Right
>>Thing. (The alternative, if we insist on glueing the two parts back
>>together, is to define how we're going to do it in a way that doesn't
>>lose information.)
>
>
> Public APIs would still take
>
> <canonical path or URL>@PEG
>
> right?
No. I was suggesting deprecating all functions that currently do so. Haven't
looked to see how feasible that would be, though. It might mean most of
libsvn_client.
Or, to develop the idea a bit further, the more precise problem is thinking
that the "@PEG" is optional in such APIs: you can't pass an arbitrary
<canonical path or URL> without a peg to such an API and guarantee that it will
be interpreted as not having a peg. Therefore another solution is to deprecate
those APIs that take
<canonical path or URL>[@PEG]
and replace them with ones that take
<canonical path or URL>@[PEG]
where the peg specifier field (starting with '@') has to be there even if there
is no peg as such.
But if we're considering doing that, I think we'd want to take the opportunity
to separate the (optional) peg into a separate argument, because that's
cleaner, given that it will already have been parsed once (before
canonicalisation) anyway.
(BTW, when I say "canonicalisation" in this thread, I really mean everything we
do to arguments, which includes character-coding conversions and auto-escaping
as well.)
> Then we have the problem of one public API calling another one.
Er... I don't follow. I guess you mean how would a deprecated function taking,
say, "THING[@PEG]", convert its argument to a form suitable for passing to a
different API taking, say, "THING@[PEG]". In the cases where such a conversion
is defined, I don't know why it would be a problem. In the cases where it's
ambiguous, like the one that started this thread ("http://name@10.0.0.1") then
we won't be any worse off than we are now.
> Or are you proposing that users of our APIs would call some public
> function to separate THING[@PEG] into a { THING, [PEG] } structure,
> and then all the other public APIs would take that structure?
Yes, something more like that. This peg-separating operation needs to be done
before or at the same time as "canonicalising" the raw arguments, so probably
during the *_args_to_target_array*() functions.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-28 19:28:35 CEST