+1 on deprecating bin/post. I haven't used it in many years either. On Tue, May 23, 2023 at 7:30 PM Joel Bernstein <joels...@gmail.com> wrote:
> 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. > > > > > > > > > -- Marcus Eagan
