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]
