I agree with Ishan on the post tool, specifically. The problem may be that people have built other tools and integrations around it.
Postman has accelerated cURL's growth for another class of users. Look at all this content about cURL and Postman if you are unfamiliar <https://www.google.com/search?q=curl+usage+postman&oq=curl+usage+postman&aqs=chrome..69i57j0i22i30l2j0i390i650l3.3310j0j7&sourceid=chrome&ie=UTF-8> . On Tue, May 23, 2023 at 2:10 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > In fact, doing these via curl will be more instructional to a user who is > using Solr for the first time. He/she will likely already know how curl > works, so will not assume there's magic happening under the hood in the > post tool. > > On Tue, 23 May 2023 at 11:38, Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > > > > * 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' > > > > AFAICT, most of them can be achieved through bash/curl with one liners. > > Bash is supported on Windows, Mac OS and GNU/Linux. Am I missing > something? > > > > On Tue, 23 May 2023 at 11:34, 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
