Hey, thanks for chiming in David, Houston, Eric! I'm glad to get a few affirmations on the general direction/approach of the design. Some responses (mostly agreement) in-line.
> I strongly prefer to move our functionality to implement the new API as at > its core/directly, and then have v1 be a shim on top Agree completely. That's the best way I can think of to make sure that v2 doesn't fall behind v1: make v1 the shim and put the "real" logic in v2. That was a primary motivation in tackling the move away from the apispec framework - annotated Java classes give us a place to put logic that we didn't have when everything was JSON. I haven't started this effort yet, but plan on tracking it on SOLR-15736. > I think it would be best to tackle one limited area first so we can see it in > practice both at the surface and implementation. I think that makes sense, assuming that by "tackling" you mean updating the API path/verb/etc and moving the "real" logic over to the v2 class? I'd rather we not take a "limited area" approach to getting consensus around the API endpoint design itself, as IMO that'd produce a less cohesive result. I don't think that was what you meant, but just double-checking. Best, Jason On Thu, Jul 14, 2022 at 1:00 PM David Smiley <dsmi...@apache.org> wrote: > > I did look over it twice now, here & there. Boy, there is a big API > surface area to Solr! Thanks for working on this huge task Jason! > > I think it would be best to tackle one limited area first so we can see it > in practice both at the surface and implementation. From an implementation > perspective, I strongly prefer to move our functionality to implement the > new API as at its core/directly, and then have v1 be a shim on top. This > will lead to new/clean code in our future with legacy concerns off to the > side that will be easy to jettison some day. I think the v2 we have today > didn't take that approach. > > I'm not familiar with OpenAPI, but based on the conversations here, I love > the prospect of having our users in various languages more easily talk to > Solr. Maybe it could be used in Solrj to reduce code maintenance as well. > Overall, similar to Swagger, which I have used in a POC and immediately > loved that I had a simple UI that I didn't have to write/maintain. > > Let's not constrain ourselves with supporting the current v2 API on Solr > 10! Doing so increases the risk that this API change won't even happen in > the first place because it's too hard. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Thu, Jul 14, 2022 at 7:00 AM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > > > Hey all, > > > > Wanted to give another "plug" to the spreadsheet of proposed v2 API > > changes, in case folks missed it the first time around. Please take a > > look and review whenever you get a chance! > > > > > > https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing > > > > > Love to see CORS support added > > > > I'm not a CORS expert, so maybe I'm misunderstanding it, but I always > > thought CORS was a security feature that was somewhat independent from > > an APIs shape/design? Do endpoints need to be designed "for" CORs in > > some way I'm missing? Just trying to understand if and how it'd > > dovetail with the v2 effort here. > > > > Best, > > > > Jason > > > > On Thu, Jul 7, 2022 at 8:20 AM Eric Pugh > > <ep...@opensourceconnections.com> wrote: > > > > > > Love to see CORS support added ;-) > > > > > > > > > On Jul 6, 2022, at 9:45 AM, Jason Gerlowski <gerlowsk...@gmail.com> > > wrote: > > > > > > [Jan] I think it is better for the project to evolve and fix this > > > > > > > > > Glad to hear it; sorry for the confusion if I misunderstood your > > concerns! > > > > > > Well in that case it sounds like there's general support for the idea > > > of broader changes to the v2 API, and no categorical objections > > > (albeit a few concerns about helping users upgrade, etc.) > > > > > > Of course, there'll need to be a good bit of discussion still around > > > what specific changes to make. REST and OpenAPI support are the two > > > things that've come up repeatedly in past discussions, so I've gone > > > ahead and put together a Google Sheet with first-drafts of the changes > > > each API would need if we go in that direction. I've attached the > > > sheet to SOLR-15871 ("Cosmetic and consistency improvements for the v2 > > > API") and linked it below. Hopefully that'll be a good way to > > > kickstart the discussion. > > > > > > > > https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing > > > > > > Thanks all for the feedback so far! > > > > > > Best, > > > > > > Jason > > > > > > On Tue, Jun 21, 2022 at 4:25 AM Jan Høydahl <jan....@cominvent.com> > > wrote: > > > > > > > > > I'd love to find a way to > > > address your concerns and still evolve v2 without backcompat, if we > > > can. > > > > > > > > > I just wanted to highlight that some users may be using v2 without > > realizing it was experimental due to the back-and-forth communication we > > have had on this. > > > Personally I think it is better for the project to evolve and fix this, > > even if that means we'll put extra migration effort on some v2 users in > > minor releases. We'd of course need to clearly mark such changes so it > > won't come as a surprise. > > > > > > Jan > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > _______________________ > > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com | My Free/Busy > > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > > 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. > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
