Sure, we could do CMSs as a category. I think there would be about 10 entries or so.
Regards, Alex Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 3 December 2014 at 12:24, [email protected] <[email protected]> wrote: > Nice! > > I like the title “Solr Ecosystem” so I propose the SolrIntegration content > by moved there, but it’s not critical to me that the content move that way > vs the other. > > I think when listing projects grouped by source code language, it’s > important to make further distinctions as to what the nature of the project > is. Some are just clients, some are actually response formats Solr natively > supports, and some are fundamentally integrated with another framework (e.g. > Rails or Django). It’s good to see some of that here… but it’s weird to see > Haystack (a Django plug-in) down in the unorganized list at the bottom > “Integrating Solr with Other (Non Search) Applications”. CMSs should get > their own category. > > ~ David Smiley > Freelance Apache Lucene/Solr Search Consultant/Developer > http://www.linkedin.com/in/davidwsmiley > > On Wed, Dec 3, 2014 at 8:36 AM, Alexandre Rafalovitch <[email protected]> > wrote: >> >> +1 on merging those two. But also needs a bit of a 'design' of what >> goes into it. I have probably another 30 links of various Solr-related >> products. >> >> I didn't touch SolrPython page because it had that extra information >> compared to just one liners on the main screen. And I didn't have the >> time to review whether those examples are still valid or need to be >> present. Same with SolrPHP legacy stuff I linked to. >> >> Another pass through this would be nice. >> > For example, little did I know there was a client for Solr for the Rust >> > programming language. >> And four for Clojure :-) >> >> Regards, >> Alex. >> Personal: http://www.outerthoughts.com/ and @arafalov >> Solr resources and newsletter: http://www.solr-start.com/ and @solrstart >> Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 >> >> >> On 3 December 2014 at 08:28, Eric Pugh <[email protected]> >> wrote: >> > Maybe this should just be one long page? David and I were thinking of >> > merging it, since it’s an arbitrary split anyway between IntegratingSolr >> > and >> > the SolrEcosystem pages. After all, it’s all part of the SolrEcosystem! >> > >> > One of the reasons I like having this all pulled together into one place >> > is that it shows new users how much breadth and depth there is! For >> > example, little did I know there was a client for Solr for the Rust >> > programming language. >> > >> > Maybe merge IntegratingSolr and SolrEcosystem and SolPython? And rename >> > SolPython to SolrPython, and put a link with just the example code bits? >> > >> > Eric >> > >> >> On Dec 3, 2014, at 12:23 AM, Alexandre Rafalovitch <[email protected]> >> >> wrote: >> >> >> >> Ok, >> >> >> >> Done: https://wiki.apache.org/solr/IntegratingSolr >> >> Also: https://wiki.apache.org/solr/SolPython >> >> >> >> I am not sure what to do with the stuff at the bottom of the client >> >> list, though I've put the dates on it anyway. It's neither >> >> comprehensive nor representative and I don't understand the >> >> significance of that part vs. >> >> https://wiki.apache.org/solr/SolrEcosystem . But that's all I had >> >> patience for this time with WIKI being an absolute turtle. Perhaps >> >> somebody else can revisit it with a fresh eye now that I cleaned it up >> >> a bit. >> >> >> >> Regards, >> >> Alex. >> >> Personal: http://www.outerthoughts.com/ and @arafalov >> >> Solr resources and newsletter: http://www.solr-start.com/ and >> >> @solrstart >> >> Solr popularizers community: >> >> https://www.linkedin.com/groups?gid=6713853 >> >> >> >> >> >> On 1 December 2014 at 20:04, [email protected] >> >> <[email protected]> wrote: >> >>> I like the “last updated …” (rounded to the month) idea. It may be >> >>> difficult to maintain a “last checked” distinction, and create >> >>> somewhat more >> >>> of a burden on maintaining the list. I think it’s useful to list out >> >>> old >> >>> projects, maybe separately, and indicated as old. This makes the page >> >>> a >> >>> better comprehensive resource. >> >>> >> >>> Thanks for volunteering Alex! >> >>> >> >>> ~ David Smiley >> >>> Freelance Apache Lucene/Solr Search Consultant/Developer >> >>> http://www.linkedin.com/in/davidwsmiley >> >>> >> >>> On Mon, Dec 1, 2014 at 7:35 PM, Alexandre Rafalovitch >> >>> <[email protected]> >> >>> wrote: >> >>>> >> >>>> What would be the reasonable cutoff for the client library last >> >>>> update? Say if it was not updated in 2 years - should it be included >> >>>> in the list? In 3? Included with a warning? >> >>>> >> >>>> Or do we list them all and let the user sort it out? Or put a >> >>>> last-checked date on the wiki and mention rough last update against >> >>>> each library? >> >>>> >> >>>> Regards, >> >>>> Alex. >> >>>> Personal: http://www.outerthoughts.com/ and @arafalov >> >>>> Solr resources and newsletter: http://www.solr-start.com/ and >> >>>> @solrstart >> >>>> Solr popularizers community: >> >>>> https://www.linkedin.com/groups?gid=6713853 >> >>>> >> >>>> >> >>>> On 1 December 2014 at 11:03, Eric Pugh >> >>>> <[email protected]> >> >>>> wrote: >> >>>>> I think in the vein of a “do-it-tocracy”, getting the Wiki updated >> >>>>> is a >> >>>>> perfectly good first step, and then if there is a better approach, >> >>>>> hopefully >> >>>>> that occurs.… ;-) >> >>>>> >> >>>>> >> >>>>> >> >>>>>> On Dec 1, 2014, at 10:51 AM, Alexandre Rafalovitch >> >>>>>> <[email protected]> >> >>>>>> wrote: >> >>>>>> >> >>>>>> On 1 December 2014 at 10:02, [email protected] >> >>>>>> <[email protected]> wrote: >> >>>>>>> I meant to reply earlier... >> >>>>>>> >> >>>>>>> On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch >> >>>>>>> <[email protected]> >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> They are super-stale >> >>>>>>> >> >>>>>>> >> >>>>>>> Yup but it’s a wiki so feel free to freshen it up. I’ll be doing >> >>>>>>> that >> >>>>>>> in a >> >>>>>>> bit. It may also be helpful if these particular pages got more >> >>>>>>> prominence/visibility by being linked from the ref guide and/or >> >>>>>>> the >> >>>>>>> website. >> >>>>>> >> >>>>>> On the TODO list. If you are planning to update the client list, >> >>>>>> maybe >> >>>>>> we should coordinate, so we don't step on each other's toes. I am >> >>>>>> planning to do more than a minor tweak. >> >>>>>> >> >>>>>>>> and there is no easy mechanism for people to >> >>>>>>>> announce their additions. I am not even sure the announcements >> >>>>>>>> are >> >>>>>>>> welcome on the user mailing list. >> >>>>>>> >> >>>>>>> >> >>>>>>> IMO the mailing list is an excellent place to announce new Solr >> >>>>>>> integrations >> >>>>>>> in the ecosystem out there. People announce various things on the >> >>>>>>> list from >> >>>>>>> time to time. >> >>>>>> I haven't even announced solr-start.com on the list, wasn't sure >> >>>>>> whether it's appropriate. So, maybe it's ok, but I suspect that's >> >>>>>> not >> >>>>>> visible. >> >>>>>> >> >>>>>>>> It comes down to the funnel/workflow. At the moment, the workflow >> >>>>>>>> makes it _hard_ to maintain those pages. CMM level 1 kind of >> >>>>>>>> hard. >> >>>>>>> Can you recommend a fix or alternative? >> >>>>>> >> >>>>>> I thought that's what my previous emails were about?!? Setup a >> >>>>>> 'client-maintainer' mailing list seeded with SolrJ people, update >> >>>>>> the >> >>>>>> Wiki, make it more prominent. Organize a TodoMVC equivalent for >> >>>>>> Solr >> >>>>>> clients (with prizes?). Ensure it is a topic (with mentor) for >> >>>>>> Google's Summer of Code. Have somebody from core Solr to keep at >> >>>>>> least >> >>>>>> one eye on the client communities' mailing lists. >> >>>>>> >> >>>>>> I started doing that as an individual, but the traction was not >> >>>>>> there. >> >>>>>> It needs at least a couple of people to push in the same direction. >> >>>>>> >> >>>>>> Regards, >> >>>>>> Alex. >> >>>>>> >> >>>>>> >> >>>>>> --------------------------------------------------------------------- >> >>>>>> To unsubscribe, e-mail: [email protected] >> >>>>>> For additional commands, e-mail: [email protected] >> >>>>>> >> >>>>> >> >>>>> ----------------------------------------------------- >> >>>>> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | >> >>>>> http://www.opensourceconnections.com | My Free/Busy >> >>>>> Co-Author: Apache Solr 3 Enterprise Search Server >> >>>>> 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. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: [email protected] >> >>>>> For additional commands, e-mail: [email protected] >> >>>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: [email protected] >> >>>> For additional commands, e-mail: [email protected] >> >>>> >> >>> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> > ----------------------------------------------------- >> > Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | >> > http://www.opensourceconnections.com | My Free/Busy >> > Co-Author: Apache Solr 3 Enterprise Search Server >> > 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. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
