Re: GDataInputStream API break

[Alexander Larsson <alexl redhat com>]

On Thu, 2009-11-12 at 15:12 -0500, Ryan Lortie wrote:
> Hi
> 
> I want to make a small break to the API of GDataInputStream.
> 
> The details are in bug #584284.
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=584284
> 
> 
> The summary:
> 
> When I implemented the async versions of read_line() and read_until() I
> got the semantics of the read_until_async() function very slightly
> different than the read_until() one.  Specifically: read_until() will
> consume the separator character, and read_until_async() will not.  My
> bad.
> 
> In my defence, the documentation has no verbiage to indicate that the
> separator character will be consumed by either function and in the
> absence of such statements I'd believe that it wouldn't.
> 
> 
> I agree with the reporter that it is sufficiently weird to have
> slightly-different async vs. sync version that is warrants breaking the
> API.  I also believe that it is likely that the _async() version has
> seen less use, so probably fewer problems would be caused by changing it
> rather than the synchronous one.

I don't like breaking API like this. Especially since I think its the
sync call that is really broken, and we should not also break the async
one.

Maybe we can do something like:
Add g_data_input_stream_read_until2() which doesn't consume the input.
#define g_data_input_stream_read_until g_data_input_stream_read_until2
Add a (rate limited?) g_warning to g_data_input_stream_read_until()
explaining the issue..

This would keep old binaries "working" but producing warnings that will
help these apps handle this case.