Jason G and I were chatting about if we need to back port to the 8X line every change made to enhance the V2 APIs, and my thought was that part of the “experimental” tag is that we could just work in the main code base. This would make it easier to move quicker and not always have that “how is this going to work in in 8X” question in the back of our minds...
If we get to a point where we feel good about the API and want to do a back port to some future 8X release we could, but that we shouldn’t feel constrained to do that for every small improvement to every API. Thoughts? > On Nov 5, 2021, at 9:27 AM, Gus Heck <[email protected]> wrote: > > Once I get the core-container split out into it's own > provider/service/whatever started by a context listener, we should do v3 as a > servlet giving us a clean slate, and easy access to verbs. I suspect v2 was > made much more difficult by the fact that it had to co-exist with a lot of > other code inside a filter. > > On Fri, Nov 5, 2021 at 6:04 AM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > +1 to experimental > > If we want to be more standards-based, embrace OpenAPI and perhaps more > standardized RBAC frameworks, then I believe there will be a v3 API based on > JAX-RS or something, with more active use of http verbs. > While v2 is harder for devs to use and remember, it has somewhat better > practices wrt no mutating state with GET requests, which is the worst thing > about v1 imo. > > Even a v2 or v3 API can have some "convenience" things built-in. I.e. > allowing common operations with a simple URL param rather than having to add > a POST body for all. > > Jan > >> 5. nov. 2021 kl. 10:54 skrev Eric Pugh <[email protected] >> <mailto:[email protected]>>: >> >> I can live with “experimental” ;-) >> >>> On Nov 4, 2021, at 6:42 PM, Shawn Heisey <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On 11/4/21 1:20 PM, Jason Gerlowski wrote: >>>> With that in mind, I think the next steps here should probably be to: >>>> >>>> 1. decide what label or term we want to go with ("evolving"? >>>> "experimental"? "beta"?), and >>>> 2. figure out what the best way to publicize change in policy. >>>> >>>> For (1) my vote is probably still "experimental". If others care >>>> enough to chime in though I'm happy to go with whatever's most >>>> popular. >>> >>> From what I have seen, an experimental designation is the right way to go >>> for v2. If we don't do that, then I think we have to cease development on >>> v2 and create something like v3, designating THAT as experimental. I don't >>> see much value in coming up with a synonym that means the same thing. >>> >>>> Eric expressed some concern that "experimental" implies that v2 might >>>> not get adopted. IMO that implication might not be a bad thing; >>>> Houston is talking about making the APIs more RESTful, Tim wants to >>>> add OpenAPI support, and there were lots of other changes suggested in >>>> this thread alone. >>> >>> >>> Also from what I have seen, v2 is not ready for adoption yet, so I think we >>> call it experimental and get ready to really overhaul it. I believe I >>> heard somebody say it's incomplete compared to the original API, plus the >>> community has a lot of ideas about major additions and/or fundamental >>> changes in its design. If we eat our own dog food by using the v2 API in >>> things like SolrJ, scripts, and the admin UI, we are more likely to try and >>> come up with stable designs that don't need to be thrown out frequently. >>> The experimental designation would make it possible for us to throw >>> something out and begin again if we find that the existing design of that >>> component is too limiting. >>> >>> I would like to eventually (in 10.0, maybe) get to a point where we declare >>> the original API as deprecated and remove the experimental designation from >>> v2. At that point we only make new bells and whistles available in v2 ... >>> and then a major version or two after that, we remove the old API entirely. >>> Backward compatibility is an important goal to strive for, but it can't be >>> maintained forever. >>> >>> This is possibly a pipe dream: I would like a new API to be able to do as >>> much as possible with URL parameters, only REQUIRING a body on the request >>> for things that are complex, or where a body is a natural pathway, like >>> indexing. Of course it should also be possible to put EVERYTHING into the >>> body and send no URL parameters at all. I think they call this wanting to >>> have my cake and eat it too. :) Like I said ... might be a pipe dream. >>> >>> Something I have found to be invaluable is the fact that a LOT of things >>> can be done and tested with the original API simply by typing a URL into a >>> browser. If everything MUST be done with a request body, I would find that >>> to be extremely inconvenient. If the community thinks that's the right >>> thing to do, then I will adapt. It's not all that difficult to send a body >>> with something like curl. And that requirement might make people more >>> cautious about how they interact with Solr. >>> >>> Thanks, >>> Shawn >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> <mailto:[email protected]> >>> For additional commands, e-mail: [email protected] >>> <mailto:[email protected]> >>> >> >> _______________________ >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com <http://www.opensourceconnections.com/> >> | My Free/Busy <http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> This e-mail and all contents, including attachments, is considered to be >> Company Confidential unless explicitly stated otherwise, regardless of >> whether attachments are marked as such. >> > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play) _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
