On 6/4/07, Ivan Zhakov <chemodax@gmail.com> wrote:
> On 6/5/07, Mark Phippard <markphip@gmail.com> wrote:
> > On 6/4/07, Ivan Zhakov <chemodax@gmail.com> wrote:
> > > On 5/30/07, Mark Phippard <markphip@gmail.com> wrote:
> > > I totally agree with you that Subversion should able use Win32 api
> > > instead iconv for encoding conversion on Windows. Maintaining iconv on
> > > windows is hell now. But as I remember last discussion on this topic
> > > blocked by Branko (http://svn.haxx.se/dev/archive-2005-10/0683.shtml):
> > > >> Anyway... before proceeding any further with this patch, I'd like to see
> > > >> some definite answers about the recent report that Windows translation
> > > >> functions aren't reliable for all encodings. If that's true, repllacing
> > > >> apr_iconv would be taking a step backwards (and would therefore generate
> > > >> a -1 from me).
> >
> > I think to be fair here, someone needs to raise a more specific
> > objection, such as pointing to an actual flaw not a hypothetical one.
> > I could turn this around and point to dozens of known crashes of
> > Windows because we use apr_iconv.
> It was not my objection :) I'm just pointing to Brane objection and his -1.
> Personally I don't see problems to use win32 api, even it doesn't
> support some encoding. User will get problems with these encodings on
> OS level anyway.
Even in his objection Brane said "if this is true". All I (and
Stefan) am saying is we need a more specific objection. If there are
real problems that we cannot resolve, then I am sure we would all be
against this. But we know there are problems with apr_iconv too, so
let's just understand what the problems are.
> > > I consider that right way is to teach apr-iconv use win32 api instead
> > > if doing this in Subversion itself. Also in apr-iconv we can hardcode
> > > names of encodings supported by Windows (as far I know Windows
> > > supports limited set of encodings)
> > >
> > > Also I had some technical comments on Stefan's patch. But I'm ready to
> > > solve it if we get some decision in concept.
> >
> > There is so little code here, why involve apr_iconv? I think we
> > should just dump it.
> >
> I consider that OS abstraction is apr_iconv responsibility. I don't
> like idea to have list of hardcoded encoding names in Subversion code.
> We need to list them to support --encoding option. But I could change
> my mind.
>
> So we have to argue Branko and choose location of this code: in
> Subversion or in apr-iconv.
My knowledge in this area always bounces back and forth. I thought we
were not using apr_iconv on other platforms. Is the issue that we do
use it, but if "iconv" is available that gets used instead?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 4 23:39:04 2007