+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. > >
