Re: G_SEEK_CUR and stateless iconv encodings

[Owen Taylor <otaylor redhat com>]

rsteinke w-link net writes:

> 	Those of you who are familiar with the changes in GIOChannel
> in glib 2.0 may remember that it is impossible to do certain things,
> like seek with G_SEEK_CUR or mix reads and writes to a file, unless
> the channel's encoding is NULL (binary) or UTF-8. The reason for these
> difficulties is that certain things in the backend cannot be accomplished
> with iconv() for channels with stateful encodings.
> 	It has occured to me that there is no reason, if we had a way of
> determining which encodings were and were not stateful, that the user
> shouldn't be able to do everything with the stateless encodings that can
> be done with UTF-8. It might be useful to have a larger set of encodings
> (perhaps the various unicodes, UTF-16, and ASCII, in addition to UTF-8)
> which are known to be stateless, for which we could provide random access
> to files. I would appreciate suggestions as to what encodings this set
> should contain.
> 	My question is, would this be an API change? It doesn't add any
> new functions; it only touches the header file to add a bitflag to the
> GIOChannel structure. The rest is changes to the backend, and (still
> unimplemented) changes to the docs. I've attached the patch below
> for anyone who's interested. The "UTF-8 like" encodings would be
> specified in enc_list in check_encoding_stateful().

Well, it _is_ an API change, but we've snuck in some other small
"API changes that don't change the function headers.

However, but I think it's something that can easily wait until after
2.0. I don't think either seeking from the current position or mixing
reads and writes is something that is going to be done very often,
especially not on a stream with encoding conversion.

I'd like to hold off on this, if you don't mind. You might want to
file a bug in bugzilla to track the issue.

Regards,
                                        Owen