Lots of feedback! So, would renaming SOLR-6994 from "Implement Windows version of bin/post" to “Implement Windows version of bin/post via implementing bin/solr post” address your concern David?
It’s both for Solr technical simplicity, but also to let Window’s users actually have better support. In the not too distant future I want to get BASIC and JWT auth across all our CLI tools and not having this one orphaned “bin/post” and random checked in “post.jar” hanging out would help that. I don’t think we can remove the capability to post documents completely, that it has to be deprecated. And honestly, if the darn thing worked a bit better (like in the aforementioned more secure scenarios) then it would provide plenty of value. > On May 23, 2023, at 2:16 AM, Marcus Eagan <marcusea...@gmail.com> wrote: > > Smiley, that's actually a pretty good use case. > > On Tue, May 23, 2023 at 2:15 AM David Smiley <dsmi...@apache.org> wrote: > >> Glad to see we can limit this discussion to "bin/post" and not >> other non-prod/maybe-prod things listed. >> >> I think bin/post should either exist where it is or not exist; moving it to >> the sandbox misses the point. >> "curl" may very well be plenty adequate. FWIW your arguments work for me >> to ditch bin/post, but it could be useful to hear from educators/trainers >> as well. It's been a while since I could count myself as such. >> >> BTW I know of at least one advantage over curl. I was once posting massive >> many-gigabyte files to Solr in CSV (for a POC scenario). Curl wanted to >> memory-map the whole thing and failed to get the RAM to do it. "bin/post" >> streamed the whole thing quite fast. I know I made improvements to help it >> in this specific regard. That said, if bin/post is mostly redundant, I >> wouldn't want us to maintain bin/post forever *just* because of this. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Tue, May 23, 2023 at 2:05 AM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >>> We have advertised the post tool in the past in our examples/tutorials. >>> Difficult to erase all traces of it from the web. >>> It is better to remove the tool from the Solr distro, and, maybe, >> relocate >>> it to the sandbox/extras repo, from where a user can consciously choose >> to >>> download and use it if needed. >>> >>> If we have proper documentation, I don't see how anyone building POCs >> will >>> miss out on the post tool. Is there a use case that users can't achieve >>> easily through a documented method that the post tool caters to? >>> >>> On Tue, 23 May 2023 at 11:25, David Smiley <dsmi...@apache.org> wrote: >>> >>>> Ishan, your beliefs surprise me. Maybe I'm misunderstanding your point >>> of >>>> view... is the key word of your response "advertise" and we can then >>> debate >>>> what that means? In other words, are you saying bin/post (and other >>> things >>>> you don't think should be used in production) should not exist at all >> or >>> we >>>> should be very careful about how we "advertise" its existence? I think >>>> features that help people build POCs / explore / learn are good things, >>>> even if not used typically in production. At times we over-advertised >>>> features without enough disclaimers on the suitability of the feature >> in >>>> question. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>>> >>>> On Mon, May 22, 2023 at 10:09 PM Ishan Chattopadhyaya < >>>> ichattopadhy...@gmail.com> wrote: >>>> >>>>>> Ishan, you did not give an argument for why you believe bin/post >>> should >>>>> go away. Do you feel it is better to document all the cURL commands >> to >>> be >>>>> more "standard"? >>>>> >>>>> Precisely! We should never advertise anything that shouldn't be used >> at >>>>> scale or in production. That includes the post tool, example modes of >>>>> startup, schemaless/data-driven etc. >>>>> >>>>> Curl is popular enough on Windows as well, through ports or WSL. >> There >>>> are >>>>> tools like Insomnia or Postman too. We should encourage their use, >>> rather >>>>> than promote our home grown tool by shipping oob and/or referring to >> it >>>> in >>>>> tutorials. >>>>> >>>>> On Tue, 23 May, 2023, 3:26 am David Smiley, <dsmi...@apache.org> >>> wrote: >>>>> >>>>>> *If* bin/solr is to subsume bin/post, I think it deserves its own >>>> issue; >>>>>> should not be a detail of SOLR-6994 -- "Implement Windows version >> of >>>>>> bin/post". Really; wow that'd be sneaky to do something so visible >>> to >>>>>> users / documentation under a OS/platform compatibility oriented >>> title. >>>>>> >>>>>> I am strongly not a fan of having bin/solr subsume bin/post. >>> bin/post >>>> is >>>>>> very distinct enough in purpose to remain separate. The stated >>>>> motivation >>>>>> seems out of convenience to Solr internal workings, which doesn't >>> serve >>>>> the >>>>>> user's best interests IMO. >>>>>> >>>>>> ~ David Smiley >>>>>> Apache Lucene/Solr Search Developer >>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>> >>>>>> >>>>>> On Wed, May 17, 2023 at 7:33 AM Eric Pugh < >>>>> ep...@opensourceconnections.com >>>>>>> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> As part of SOLR-6994 I’m migrating the SimplePostTool to be part >> of >>>>>>> bin/solr commands. >>>>>>> >>>>>>> >>>>>>> We document a number of example use cases: >>>>>>> >>>>>>> * JSON file: bin/solr post -url >>> http://localhost:8983/wizbang/update >>>>>>> events.json >>>>>>> * XML files: bin/solr post -url >>> http://localhost:8983/records/update >>>>>>> article*.xml >>>>>>> * CSV file: bin/solr post -url >>> http://localhost:8983/signals/update >>>>>>> LATEST-signals.csv >>>>>>> * Directory of files: bin/solr post -url >>>>>>> http://localhost:8983/myfiles/update ~/Documents >>>>>>> * Web crawl: bin/solr post -url >>>>>>> http://localhost:8983/gettingstarted/update >>> https://solr.apache.org/ >>>>>>> -recursive 1 -delay 1 >>>>>>> * Standard input (stdin): echo '{commit: {}}' | bin/solr post >> -url >>>>>>> http://localhost:8983/my_collection/update -type >> application/json >>>> -out >>>>>>> yes -d >>>>>>> * Data as string: bin/solr post -url >>>>>> http://localhost:8983/signals/update >>>>>>> -type text/csv -out yes -d $'id,value\n1,0.47' >>>>>>> >>>>>>> >>>>>>> The last two, stdin and data as a string, feel rather obscure to >>> me, >>>>> and >>>>>>> I’d like to not port them over to being supported by the bin/solr >>>> post >>>>>> tool >>>>>>> equivalent. Thoughts? >>>>>>> >>>>>>> Eric >>>>>>> _______________________ >>>>>>> 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. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > -- > Marcus Eagan _______________________ 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.
