[GitHub] [solr] epugh commented on pull request #975: SOLR-16347: Allow JAX-RS v2 API definition

[GitBox <gi...@apache.org>]

epugh commented on PR #975:
URL: https://github.com/apache/solr/pull/975#issuecomment-1241042225

   > Found a buried question from @dsmiley that I'd failed to answer:
   > 
   > > do you think your work here might be better characterized as a V3 API rather than changing V2? Of course we agreed to change V2 as we see fit but I'm just wondering if you are hampered by lots of code already existing for V2.
   > 
   > In some ways this work does _feel_ like a v3 effort. Particularly because we're integrating a new (to Solr) API framework. But from the user or API-consumer perspective I think this is "just" v2 hardening and refactoring. We're not introducing new APIs that will exist alongside their v2 counterparts, etc. So I personally tend to think of this work as "v2".
   > 
   > In terms of the development, the existing v2 code hasn't done too much "hampering". Of course, in terms of this specific PR, it's been a big pain to add JAX-RS support to V2HttpCall while still keeping the existing `Api` and introspect codepaths there working. But I don't see that being much of a problem on an api-by-api basis as we add new or convert existing endpoints over to JAX-RS.
   > 
   > > Lots of V2 classes could be marked Deprecated to communicate our intent to not take it into the future.
   > 
   > I'm all for deprecating some of the existing (but now legacy?) v2 framework, especially: `Api`, `ApiBag`, `ApiSupport`, `Command`, `PayloadObj`, `AnnotatedApi`, etc.
   > 
   > I'd probably wait on adding those deprecations until we have a bit more history converting things over to JAX-RS, but in a few month's time I'd love to push up a PR for that. I don't want to put the "cart before the horse" there though.
   
   I'll chime in a bit too...   We did decide to mark V2 API's as experimental, so that we could free ourselves up to change them ;-).    


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org