I have mixed feelings about this because I love command line tools. But I haven't actually used the bin/post tool in years.
On Tue, May 23, 2023 at 10:13 AM David Smiley <dsmi...@apache.org> wrote: > +1 to deprecate bin/post. > > Eric, RE the issue title... it's better. Still, if I were advocating for > the work (and I'm definitely not), I'd have a dedicated issue nonetheless, > may or may not even have a separate Windows issue if it gets fixed by side > effect of moving the functionality. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, May 23, 2023 at 6:05 AM Eric Pugh <ep...@opensourceconnections.com > > > wrote: > > > 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. > > > > >
