Greg Stein <firstname.lastname@example.org> writes:
> > Perhaps I'm confused as to what you're suggesting. How far towards the
> > edge do you want to push this encoding? If you're not using ra_dav, I
> > don't think there's any need to URI-encode dirent names at all.
> *de*coding. We already require that incoming URIs are properly
> encoded. Thus, there is also the notion that all URIs within the
> SVN libraries should be encoded already. Thus, we want to keep
> things in an encoded state.
I think Greg H. knows what you're talking about. What he's saying,
though, is that ra_svn and ra_local don't pass around URIs internally
-- they don't need to, because they're not talking to a web server
that so requires. So for them to implement the __get_dir() interface
that you proposed means that they have to actually URI-*en*code their
results before handing them back to the user (who will then
immediately URI-*de*code them.
Only ra_dav plays with URIs internally.
So, what was that about the ra-layer defining the interfaces? :-) I'm
kidding, of course, because the destructiveness of a URI-decode
operation is important to note.
That said, where *do* we draw the line on these encodings? For
example, we drive editors all the time against the RA library, and we
don't URI-encode the input to those editors -- ra_dav does that
internally. The ra->check_path() interface takes non-URI-encoded
strings. The reporter interface -- the same. The MERGE response
bump_handler() code does URI-decoding before calling a client
callback, yet other callbacks seem to use relative URLs.
My points: a) There are no well-defined rules about the URI "lines" in
the RA interface. b) As a result, there's world of inconsistency going
on in there, and c) perhaps we should have an intelligent discussion
about this situation.
> The change to __get_dir *decodes* a URI and returns that from a library.
> That doesn't make sense. That decoding can also lose information, which
> means that the code which is calling RA cannot turn the URI around and use
> it with the SVN libraries.
...and I have all too recent memories of the pain that this kind of
early decoding can cause...
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jun 2 15:11:57 2003