On Wed, 21 Jul 2004, [UTF-8] Branko Ä^Libej wrote:
> Peter N. Lundblad wrote:
>
> >On Tue, 20 Jul 2004, C. Michael Pilato wrote:
> >
> >
> >
> >>"Peter N. Lundblad" <peter@famlundblad.se> writes:
> >>
> >>
> >>
> >>>So, if no one has any good reasons, I'd like to use the first approach
> >>>above, keeping compability between 1.1 and 1.2. Any objections?
> >>>
> >>>
> >>No objection here.
> >>
> >>We're making this change to enhance the user experience. I might be
> >>missing something, but I see no gain in switching our internal storage
> >>format (and the promises of all our interfaces), especially if we have
> >>to convert back just to use the one protocol that actually demands
> >>URLs (HTTP).
> >>
> >>
> >>
> >That was a good way of expressing it:-)
> >
> >I am going for the way I proposed...
> >
> >
> I'd like to propose that for 2.0, we _do_ change our internal format to
> IRI and let the RA layer handle any conversions. The reason is simple:
> there are other clients apart from the command-line client that don't
> use svn_opt_args_to_target_array. As it stands for 1.0, these clients
> will have to reimplement (or copy our implementation of) IRI->URI
> translation, which seems like a bit of a pain.
>
They need to call svn_path_uri_from_iri (possibly preceded by
svn_path_url_autoescape). STill, it might be good to change to IRI in 2.0.
cmplilato's question could be turned around: why encode just to decode for
the protocols that *could* use IRI directly (ra_local and ra_svn) and
user messages? Wuld you mind filing an issue?
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 21 19:41:17 2004