On Sun, 17 Oct 2004, Erik Huelsmann wrote:
> > My proposal is to add support for recoding and eol translation to our
> > svn_stream_t interface. Then we should use streams instread of apr_file_t
> > whereever possible, such as in svn_client_diff. It should be possible to
> > set the encoding for a stream and turn it into text/binary mode.
>
> > Why not just stack a recoding stream onto an existing stream like we do
> > for compression? That's because the creator of the stream knows the
> > encoding it should be outputing, but the user of the stream may need to
> > turn it into binary mode.
>
> Right. This is exactly the approach I was using. This is not a
> solution for the use-case of libsvn_diff however: There you have some
> output which needs recoding and some which doesn't. All that needs to
> end up in the correct order in the output stream. I was still thinking
> about what to do there, but I think there are 2 solutions: tell the
> diff lib which encoding the header should be, let it recode and send
> the output (just as it is now) to the stream. Or you can add a
> callback. Tell the client you are passing it header or file
> information and let the client decide what to do....
>
I probably wasn't clear on the main reason to build this into the streams.
I was envisioning a way for the producer to swithc between text and binary
mode. This would help svn_diff, that outputs both headers (text) and the
file contents (raw data, since we don't know the encoding).
svn_error_t svn_stream_set_encoding(...);
const char *svn_stream_get_encoding(...);
void svn_tream_set_text_mode(..., svn_boolean_t);
svn_boolean_t svn_stream_get_text_mode(...);
My goal is to be more consistent: either use svn_cmdline_* or
svn_stream_*. We wouldn't have to explicitly recode in so many places and
care about eol conversion. But looking more closely, we have to use
apr_file_t, for example in svn_client_diff, since it is necessary for the
external diff. So, maybe we have to live with this mess. :-(
I think I'll leave the encoding problems to you for the moment. I have
enough with other things to work on when time permits...
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 18 23:22:18 2004