[squid-dev] [PATCH] implement RFC3986

[Kinkie]

>> What is the big problem with these generic template functions?
>
> I believe the problem has already been discussed. I have no new general
> information to add to that discussion, but would be happy to try to
> answer any specific questions.

Sorry to bring this topic up again, but honestly I don't understand
your position.
Rfc3986 seems to work, offers an API which is arguably cleaner than
the current rfc1738* methods, is at least as fast if not faster, and
comes with unit tests which we are currently lacking (well, live code
has worked for a long time so we may not need them, but still..)

I believe that the deadlock we currently are in is caused by the fact
that we are discussing about two topics at the same time.
One is: should Rfc3986 target both SBuf and std::string, if the
performance and complexity penalty in doing so is none or small? I
(and I believe Amos) think it's a good, or at least not a bad idea.
The other is: should we use std::string or SBuf or c-strings in
helpers? My opinion is that std::string would be preferable, yours is
that SBuf is preferable, if any change is performed over the current
state of using c-strings. I think change over current state is a good
idea, you - I believe - are averse enough to using std::string that
would prefer no change.

Can we try to decouple the two discussions and see if this helps us
reach a consensus?

My point of view is:
- having a more generic API costs us nothing - the code is compact,
readable and efficient regardless the genericity, so we should merge
Rfc3986.
- there is no performance or readability benefit in using SBuf in
helpers due to the way client code is structured. Also, we would need
to stub a lot of functionality it relies on (e.g. mempools,
statistics, cachemgr). This would create new code-paths raising the
risk of problems. Therefore I believe we should use std::string in
helpers, and in particular I will make no attempt at refactoring
helpers to use SBuf, while I have already invested some time in
refactoring to std::string and am willing to work more on that path.

What do we do, and if you disagree with my point of view, why? I will
not spend time coding on a dead-end path, obviously, and while your
preference for SBuf is clear, the root-cause of that preference is not
clear to me yet.

Thanks!

-- 
    Francesco