Bug #102471 for HTTP-Thin-UserAgent: JSON::Any is being phased out

Mon Mar 02 18:19:25 2015 ether [...] cpan.org - Ticket created

Subject:

JSON::Any is being phased out

JSON::Any is being phased out in favour of JSON::MaybeXS, which handles the edge cases more gracefully - you probably want to switch to that, unless you rely on some of the legacy stuff (e.g. JSON::DWIM and ::Syck support) in JSON::Any.

Thu Jun 25 12:53:47 2015 ether [...] cpan.org - Correspondence added

On 2015-03-02 15:19:25, ETHER wrote: Show quoted text

> JSON::Any is being phased out in favour of JSON::MaybeXS, which > handles the edge cases more gracefully - you probably want to switch > to that, unless you rely on some of the legacy stuff (e.g. JSON::DWIM > and ::Syck support) in JSON::Any.

Patch available in https://github.com/perigrin/http-thin-useragent/pull/9

Thu Jun 25 15:43:56 2015 cpan [...] prather.org - Correspondence added

On Mon Mar 02 18:19:25 2015, ETHER wrote: Show quoted text

I'm gonna need a better description of "the edge cases more gracefully" in a way that won't drive me to just patch JSON::Any ;) -Chris

Thu Jun 25 15:43:57 2015 The RT System itself - Status changed from 'new' to 'open'

Thu Dec 10 17:36:03 2015 DBOOK [...] cpan.org - Correspondence added

On Thu Jun 25 15:43:56 2015, PERIGRIN wrote: Show quoted text

> On Mon Mar 02 18:19:25 2015, ETHER wrote:

> > JSON::Any is being phased out in favour of JSON::MaybeXS, which > > handles the edge cases more gracefully - you probably want to switch > > to that, unless you rely on some of the legacy stuff (e.g. JSON::DWIM > > and ::Syck support) in JSON::Any.

> > > I'm gonna need a better description of "the edge cases more > gracefully" in a way that won't drive me to just patch JSON::Any ;) > > -Chris

Am I missing something? You yourself considered JSON::Any deprecated long ago, and JSON::MaybeXS is the same idea as JSON.pm but without being excessively slow and overcomplicated.

Thu Dec 10 17:46:03 2015 DBOOK [...] cpan.org - Cc DBOOK added

Thu Dec 10 18:28:11 2015 chris [...] prather.org - Correspondence added

Subject:	Re: [rt.cpan.org #102471] JSON::Any is being phased out
Date:	Thu, 10 Dec 2015 23:27:42 +0000
To:	bug-HTTP-Thin-UserAgent [...] rt.cpan.org
From:	Chris Prather <chris [...] prather.org>

First lemme state I deprecated JSON::Any because for 80-90% of people's needs JSON::MaybeXS was a simpler implementation with more active maintainers. I hated the initial API it provided and planned to continue using JSON::Any in my own code. Karen understands my position on JSON::Any, or at least we have a good working relationship with mutual respect. (At the very least I respect her and her opinions, she probably thinks I'm a flighty well intentioned idiot). Deprecated doesn't mean Abandoned,. It's the other end of the spectrum from "Alpha". It means that there may be issues that may or may not be fixable. You should use the code at your own risk. Since as far as I can tell I am the only maintainer of each currently (though Ether has primary permission on JSON::Any and can in fact override me I believe and shut it down entirely) ... they both fall exactly within the definition of "my own risk". That said, there is a large space better deprecating JSON::Any because a simpler better maintained solution exists and accepting this patch because the code isn't fashionable. JSON::MaybeXS doesn't have all of the functionality of JSON::Any and the downstream code I wrote HTTP::Thin::UserAgent for already uses JSON::Any. I'm a pragmatic person, my bar for changing deps at the request of people is pretty low. I'm happy to accept this patch if she can provide me an explanation of how it is broken because of the dependency in a way that is impossible to fix either locally or upstream in JSON::Any. I don't think that's unreasonable on my part. I know she's a busy woman, and we have had this conversation in several places over the years. My preference would be to fix the ungraceful edge cases upstream if possible or accept this patch if not. I hope that explains my reasoning. On Thu, Dec 10, 2015 at 5:36 PM Dan Book via RT < bug-HTTP-Thin-UserAgent@rt.cpan.org> wrote: Show quoted text

> Queue: HTTP-Thin-UserAgent > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102471 > > > On Thu Jun 25 15:43:56 2015, PERIGRIN wrote:

> > On Mon Mar 02 18:19:25 2015, ETHER wrote:

> > > JSON::Any is being phased out in favour of JSON::MaybeXS, which > > > handles the edge cases more gracefully - you probably want to switch > > > to that, unless you rely on some of the legacy stuff (e.g. JSON::DWIM > > > and ::Syck support) in JSON::Any.

> > > > > > I'm gonna need a better description of "the edge cases more > > gracefully" in a way that won't drive me to just patch JSON::Any ;) > > > > -Chris

> > > Am I missing something? You yourself considered JSON::Any deprecated long > ago, and JSON::MaybeXS is the same idea as JSON.pm but without being > excessively slow and overcomplicated. >

Thu Dec 10 18:44:54 2015 DBOOK [...] cpan.org - Correspondence added

On Thu Dec 10 18:28:11 2015, chris@prather.org wrote: Show quoted text

> First lemme state I deprecated JSON::Any because for 80-90% of people's > needs JSON::MaybeXS was a simpler implementation with more active > maintainers. > I hated the initial API it provided and planned to continue using JSON::Any > in my own code. > > Karen understands my position on JSON::Any, or at least we have a good > working relationship with mutual respect. (At the very least I respect her > and her opinions, she probably thinks I'm a flighty well intentioned > idiot). Deprecated doesn't mean Abandoned,. It's the other end of the > spectrum from "Alpha". It means that there may be issues that may or may > not be fixable. You should use the code at your own risk. Since as far as I > can tell I am the only maintainer of each currently (though Ether has > primary permission on JSON::Any and can in fact override me I believe and > shut it down entirely) ... they both fall exactly within the definition of > "my own risk". > > That said, there is a large space better deprecating JSON::Any because a > simpler better maintained solution exists and accepting this patch because > the code isn't fashionable. JSON::MaybeXS doesn't have all of the > functionality of JSON::Any and the downstream code I wrote > HTTP::Thin::UserAgent for already uses JSON::Any. I'm a pragmatic person, > my bar for changing deps at the request of people is pretty low. > > I'm happy to accept this patch if she can provide me an explanation of how > it is broken because of the dependency in a way that is impossible to fix > either locally or upstream in JSON::Any. I don't think that's unreasonable > on my part. I know she's a busy woman, and we have had this conversation in > several places over the years. My preference would be to fix the ungraceful > edge cases upstream if possible or accept this patch if not. > > I hope that explains my reasoning.

Thank you for the explanation. I just want to point out that "deprecated" very definitely means that the intention is abandonment and no further updates except for critical fixes and such. It is a much more defined term (in this space) than say "discouraged" or "experimental". So with that hopefully you can understand where my confusion came from. https://en.wikipedia.org/wiki/Deprecation#Software_deprecation My only opinion is that JSON::MaybeXS should be used to maintain consistency going forward; as such I'm curious what functionality it doesn't have that JSON::Any has?

Thu Dec 10 18:55:42 2015 ether [...] cpan.org - Correspondence added

On 2015-12-10 15:44:54, DBOOK wrote: Show quoted text

> My only opinion is that JSON::MaybeXS should be used to maintain > consistency going forward; as such I'm curious what functionality it > doesn't have that JSON::Any has?

The only reason to keep using JSON::Any, that I'm aware of, is if you use one of the ancient backends like JSON::DWIW (e.g. DBIx::Class cares about this, because there's a certain edge case that it handles differently than the other backends that is apparently more "right" -- you'd have to get the details from ribasushi because I don't know if this is a right-vs-wrong thing or question of taste). The other reason would be if you're actually relying on an interface bug that JSON::Any contains that JSON::MaybeXS fixed (there is a lot of weirdness in how it handles utf8 config values between the backends -- I dare you to puzzle through how those options are translated, go on I dare you). Which is another reason to get off of JSON::Any and onto JSON::MaybeXS, actually :)

Thu Dec 10 21:03:12 2015 chris [...] prather.org - Correspondence added

Subject:	Re: [rt.cpan.org #102471] JSON::Any is being phased out
Date:	Fri, 11 Dec 2015 02:02:50 +0000
To:	bug-HTTP-Thin-UserAgent [...] rt.cpan.org
From:	Chris Prather <chris [...] prather.org>

On Thu, Dec 10, 2015 at 6:45 PM Dan Book via RT < bug-HTTP-Thin-UserAgent@rt.cpan.org> wrote: Show quoted text

> Thank you for the explanation. I just want to point out that "deprecated" > very definitely means that the intention is abandonment and no further > updates except for critical fixes and such. It is a much more defined term > (in this space) than say "discouraged" or "experimental". So with that > hopefully you can understand where my confusion came from. > > https://en.wikipedia.org/wiki/Deprecation#Software_deprecation > > My only opinion is that JSON::MaybeXS should be used to maintain > consistency going forward; as such I'm curious what functionality it > doesn't have that JSON::Any has? >

Now I'm confused. Nothing in that page says that a deprecated feature is _guranteed_ no further updates. The term 'abandon' is only used in a link to the page for Abandonware. Which conveniently is a different subject (literally). In fact two of the definitions they have are ones that I think apply to JSON::Any. 1) *The feature contains a design flaw—frequently a security flaw—and so should be avoided, but existing code depends upon it.* The feature in this case is the maintainer is unreliable. I don't have time to work on code as frequently as I should and since 80+% of the functionality is happily handled by a simpler module I deprecated in favor of that module. 2) *A future version of the software will make major structural changes, making it impossible (or impractical) to support older features.* Karen has pointed out to me (just tonight again) that there are issues that she doesn't care to track down (which is fair) with the utf8 handling in JSON::Any. She would rather use the module that fits her needs and is simpler than patch a module she likely won't be using anyway. Who can blame her? That doesn't mean that I won't at some point patch those issues. And such patches _may_ in fact break existing code because of major structural changes. So if you _can_ migrate from JSON::Any to JSON::MaybeXS then you likely _should_ migrate. So I understand your confusion, but according to the wikipedia page my actions are consistent with the given definition. So far you and Karen have the same argument for JSON::MaybeXS which is "it's the more popular/consistent/correct thing to do". From my point of view I'm not actually _fixing_ anything with this change. I'm just giving up a known state (my code all works and nobody has filed an _actual_ bug) for an unknown state (I haven't tested the patch with my own production systems that _do_ use this module, and to be blunt I'm not sure anybody else actually uses it ... I'd be really happy to be wrong there). I happen to be in an ornery mood tonight (lots of reasons mostly personal) and not just hitting "merge" to shut y'all up. I probably should've taken it to a blog but you opened the can of worms :)

Thu Dec 10 21:19:29 2015 rt-cpan [...] trout.me.uk - Correspondence added

On Thu Dec 10 18:44:54 2015, DBOOK wrote: Show quoted text

> My only opinion is that JSON::MaybeXS should be used to maintain > consistency going forward; as such I'm curious what functionality it > doesn't have that JSON::Any has?

Basically, for the goal of "pick the best available JSON implementation", JSON::MaybeXS is superior. Hence why for the majority of things JSON::Any was previously used for, it's a better approach. However, JSON::MaybeXS will never handle "try and use whatever JSON implementation you already have", because (1) AAAAAAAAAAAAAAAAAAA (2) JSON::Any already covers this beautifully. For an intentionally low-dependency module like HTTP::Thin::UserAgent that's trying hard to be easy to slot in to existing codebases with a minimum of extra requirements, JSON::Any does make logical sense - it's not necessarily the route I'd personally take, but it's absolutely still a valid route. As such, speaking as the original author of JSON::MaybeXS and a happy user of JSON::Any prior to writing JSON::MaybeXS, I would say that in the current situation my opinion is "if this code was being written anew I would write it with JSON::MaybeXS, but I see no compelling reason to convert it as it currently stands."

Thu Dec 10 21:20:10 2015 DBOOK [...] cpan.org - Correspondence added

On Thu Dec 10 21:03:12 2015, chris@prather.org wrote: Show quoted text

> Now I'm confused. Nothing in that page says that a deprecated feature is > _guranteed_ no further updates. The term 'abandon' is only used in a link > to the page for Abandonware. Which conveniently is a different subject > (literally).

Not guaranteed, no; the definition in http://perldoc.perl.org/perlpolicy.html#Terminology is similarly noncommittal, as all software is a moving target. I linked it more to show the intent that the term implies, which is that the software is not intended to be further developed and/or has been superseded, but remains for compatibility rather than being outright removed. Anyway I understand your intent with the module now, so this discussion (within this bug at least) isn't important.

Thu Dec 10 21:32:13 2015 ether [...] cpan.org - Correspondence added

On 2015-12-10 18:03:12, chris@prather.org wrote: Show quoted text

> So far you and Karen have the same argument for JSON::MaybeXS which is > "it's the more popular/consistent/correct thing to do". From my point of > view I'm not actually _fixing_ anything with this change. I'm just giving > up a known state (my code all works and nobody has filed an _actual_ bug) > for an unknown state (I haven't tested the patch with my own production > systems that _do_ use this module, and to be blunt I'm not sure anybody > else actually uses it ... I'd be really happy to be wrong there). >

And that's all totally cool! My main interest in filing the ticket was to reduce the total number of dependencies being installed, but I cannot remember why I came to *this* ticket queue in particular -- it doesn't look like $work code is using HTTP::Thin, which is the main source of my cleaning up/reducing prereqs tickets, so... do what thou will, and I shall not mind either way :)