I can live with “experimental” ;-) > On Nov 4, 2021, at 6:42 PM, Shawn Heisey <[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] > For additional commands, e-mail: [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.
