Re: solr client sdk's/libraries for native platforms
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 arafa...@gmail.com 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 ep...@opensourceconnections.com 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 arafa...@gmail.com 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, david.w.smi...@gmail.com david.w.smi...@gmail.com 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 arafa...@gmail.com 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 ep...@opensourceconnections.com 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 arafa...@gmail.com wrote: On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply
Re: solr client sdk's/libraries for native platforms
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, david.w.smi...@gmail.com david.w.smi...@gmail.com 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 arafa...@gmail.com 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 ep...@opensourceconnections.com 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 arafa...@gmail.com 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, david.w.smi...@gmail.com david.w.smi...@gmail.com 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 arafa...@gmail.com 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
Re: solr client sdk's/libraries for native platforms
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 arafa...@gmail.com 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, david.w.smi...@gmail.com david.w.smi...@gmail.com 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 arafa...@gmail.com 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 ep...@opensourceconnections.com 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 arafa...@gmail.com wrote: On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply earlier... On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch arafa...@gmail.com 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: dev-unsubscr...@lucene.apache.org For
Re: solr client sdk's/libraries for native platforms
+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 ep...@opensourceconnections.com 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 arafa...@gmail.com 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, david.w.smi...@gmail.com david.w.smi...@gmail.com 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 arafa...@gmail.com 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 ep...@opensourceconnections.com 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 arafa...@gmail.com wrote: On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply earlier... On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch arafa...@gmail.com 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
Re: solr client sdk's/libraries for native platforms
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, david.w.smi...@gmail.com david.w.smi...@gmail.com 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 arafa...@gmail.com 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 ep...@opensourceconnections.com 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 arafa...@gmail.com wrote: On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply earlier... On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch arafa...@gmail.com 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - 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: dev-unsubscr...@lucene.apache.org For additional commands,
Re: solr client sdk's/libraries for native platforms
I once asked the SolrNET developers if they would like to move their effort to Apache and become a certified client library, but the response was lukewarm. https://groups.google.com/forum/#!searchin/solrnet/apache$20lucene$20sub$20project/solrnet/lM5Xul7_nCg/5cj-iz8xbZUJ Since then the SolrNET effort seems to have almost stalled, and the committers asking money to add features :) But chances are that we'd want to model an official .NET api more closely to the Java API, not? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 24. nov. 2014 kl. 17.37 skrev Alexandre Rafalovitch arafa...@gmail.com: They are super-stale 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. 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. 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 24 November 2014 at 11:26, Eric Pugh ep...@opensourceconnections.com wrote: On the wiki are two pages listing out projects that use Solr: http://wiki.apache.org/solr/SolrEcosystem http://wiki.apache.org/solr/IntegratingSolr I noticed that they have become stale and was going to update them. Maybe they could have more prominence in the Solr site? But keep them community driven since things change so quickly. Eric On Nov 24, 2014, at 10:35 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: Well, a start would be to actually have an up-to-date list of Solr clients. I have the list, if somebody knows where it should go (Ref Guide). I don't want to contribute this to WIKI as we are trying to get rid of it. Then somebody (Summer of Code project?) would derive from that a list of clients that are up-to-date (a very different story). This would require a high-level set of features that clients are expected to cover. I have some thinking around that I am happy to share in a rough form. I would also - as mentioned before - setup a mailing list for all the client developers to discuss new features in a common way. Do not think of this as a primarily code problem - think of it as a community consolidation and establishing clear interfaces to the downstream projects. 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 24 November 2014 at 10:24, Noble Paul noble.p...@gmail.com wrote: This has been a constant pain point for Solr. Java client is a first class client where it benefits from knowing the correct servers to communicate to because it is aware of the clusterstate. The java client also has the advantage of using the faster and compact binary format. We will need to build these basic capabilities built in other languages such as C++, C# and provide bindings for other languages . We are aware of this need and any suggestions to address this are welcome On Sun, Nov 23, 2014 at 2:08 PM, Anurag Sharma anura...@gmail.com wrote: Solr interface is through REST API's which makes it easy to integrate with any platform and do binding any language. Each developer have to write common code to do the api bindings if using Solr in non java framework/platform. This overhead can be reduced by building client sdk's/libraries for popular languages and platforms e.g. - web: js, ruby, python - mobile: Objective C, Swift, C# - other: C++, Scala, perl, php Also, this can significantly reduce time to Solr on-boarding when using non java platform. Suggestions? -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail:
Re: solr client sdk's/libraries for native platforms
I meant to reply earlier... On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch arafa...@gmail.com 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. 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. 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? 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 24 November 2014 at 11:26, Eric Pugh ep...@opensourceconnections.com wrote: On the wiki are two pages listing out projects that use Solr: http://wiki.apache.org/solr/SolrEcosystem http://wiki.apache.org/solr/IntegratingSolr I noticed that they have become stale and was going to update them. Maybe they could have more prominence in the Solr site? But keep them community driven since things change so quickly. Eric On Nov 24, 2014, at 10:35 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: Well, a start would be to actually have an up-to-date list of Solr clients. I have the list, if somebody knows where it should go (Ref Guide). I don't want to contribute this to WIKI as we are trying to get rid of it. Then somebody (Summer of Code project?) would derive from that a list of clients that are up-to-date (a very different story). This would require a high-level set of features that clients are expected to cover. I have some thinking around that I am happy to share in a rough form. I would also - as mentioned before - setup a mailing list for all the client developers to discuss new features in a common way. Do not think of this as a primarily code problem - think of it as a community consolidation and establishing clear interfaces to the downstream projects. 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 24 November 2014 at 10:24, Noble Paul noble.p...@gmail.com wrote: This has been a constant pain point for Solr. Java client is a first class client where it benefits from knowing the correct servers to communicate to because it is aware of the clusterstate. The java client also has the advantage of using the faster and compact binary format. We will need to build these basic capabilities built in other languages such as C++, C# and provide bindings for other languages . We are aware of this need and any suggestions to address this are welcome On Sun, Nov 23, 2014 at 2:08 PM, Anurag Sharma anura...@gmail.com wrote: Solr interface is through REST API's which makes it easy to integrate with any platform and do binding any language. Each developer have to write common code to do the api bindings if using Solr in non java framework/platform. This overhead can be reduced by building client sdk's/libraries for popular languages and platforms e.g. - web: js, ruby, python - mobile: Objective C, Swift, C# - other: C++, Scala, perl, php Also, this can significantly reduce time to Solr on-boarding when using non java platform. Suggestions? -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
On 1 December 2014 at 09:51, Jan Høydahl jan@cominvent.com wrote: I once asked the SolrNET developers if they would like to move their effort to Apache and become a certified client library, but the response was lukewarm. https://groups.google.com/forum/#!searchin/solrnet/apache$20lucene$20sub$20project/solrnet/lM5Xul7_nCg/5cj-iz8xbZUJ And without knowing about that thread, I emailed again right from the Revolution 2014 floor when Grant announced the new focus on clients. No reply. Probably offended Mauricio :-( Either way, SolrNet's biggest issue is that the current public release does not work with recent Solr due to the interface change (some commit flag got dropped). Recompiling it from source works fine though. I raised that issue on the list before and the answer was that the release needs to have full documentation (good idea) and that somebody else should contribute that documentation (ouch). So, that's where we stand. 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply earlier... On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch arafa...@gmail.com 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
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 arafa...@gmail.com wrote: On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply earlier... On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch arafa...@gmail.com 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
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 ep...@opensourceconnections.com 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 arafa...@gmail.com wrote: On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply earlier... On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch arafa...@gmail.com 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
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 arafa...@gmail.com 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 ep...@opensourceconnections.com 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 arafa...@gmail.com wrote: On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply earlier... On Mon, Nov 24, 2014 at 11:37 AM, Alexandre Rafalovitch arafa...@gmail.com 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
This has been a constant pain point for Solr. Java client is a first class client where it benefits from knowing the correct servers to communicate to because it is aware of the clusterstate. The java client also has the advantage of using the faster and compact binary format. We will need to build these basic capabilities built in other languages such as C++, C# and provide bindings for other languages . We are aware of this need and any suggestions to address this are welcome On Sun, Nov 23, 2014 at 2:08 PM, Anurag Sharma anura...@gmail.com wrote: Solr interface is through REST API's which makes it easy to integrate with any platform and do binding any language. Each developer have to write common code to do the api bindings if using Solr in non java framework/platform. This overhead can be reduced by building client sdk's/libraries for popular languages and platforms e.g. - web: js, ruby, python - mobile: Objective C, Swift, C# - other: C++, Scala, perl, php Also, this can significantly reduce time to Solr on-boarding when using non java platform. Suggestions? -- - Noble Paul
Re: solr client sdk's/libraries for native platforms
Well, a start would be to actually have an up-to-date list of Solr clients. I have the list, if somebody knows where it should go (Ref Guide). I don't want to contribute this to WIKI as we are trying to get rid of it. Then somebody (Summer of Code project?) would derive from that a list of clients that are up-to-date (a very different story). This would require a high-level set of features that clients are expected to cover. I have some thinking around that I am happy to share in a rough form. I would also - as mentioned before - setup a mailing list for all the client developers to discuss new features in a common way. Do not think of this as a primarily code problem - think of it as a community consolidation and establishing clear interfaces to the downstream projects. 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 24 November 2014 at 10:24, Noble Paul noble.p...@gmail.com wrote: This has been a constant pain point for Solr. Java client is a first class client where it benefits from knowing the correct servers to communicate to because it is aware of the clusterstate. The java client also has the advantage of using the faster and compact binary format. We will need to build these basic capabilities built in other languages such as C++, C# and provide bindings for other languages . We are aware of this need and any suggestions to address this are welcome On Sun, Nov 23, 2014 at 2:08 PM, Anurag Sharma anura...@gmail.com wrote: Solr interface is through REST API's which makes it easy to integrate with any platform and do binding any language. Each developer have to write common code to do the api bindings if using Solr in non java framework/platform. This overhead can be reduced by building client sdk's/libraries for popular languages and platforms e.g. - web: js, ruby, python - mobile: Objective C, Swift, C# - other: C++, Scala, perl, php Also, this can significantly reduce time to Solr on-boarding when using non java platform. Suggestions? -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
FYI see https://wiki.apache.org/solr/IntegratingSolr for a list. This is a great use of the wiki. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Mon, Nov 24, 2014 at 10:35 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: Well, a start would be to actually have an up-to-date list of Solr clients. I have the list, if somebody knows where it should go (Ref Guide). I don't want to contribute this to WIKI as we are trying to get rid of it. Then somebody (Summer of Code project?) would derive from that a list of clients that are up-to-date (a very different story). This would require a high-level set of features that clients are expected to cover. I have some thinking around that I am happy to share in a rough form. I would also - as mentioned before - setup a mailing list for all the client developers to discuss new features in a common way. Do not think of this as a primarily code problem - think of it as a community consolidation and establishing clear interfaces to the downstream projects. 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 24 November 2014 at 10:24, Noble Paul noble.p...@gmail.com wrote: This has been a constant pain point for Solr. Java client is a first class client where it benefits from knowing the correct servers to communicate to because it is aware of the clusterstate. The java client also has the advantage of using the faster and compact binary format. We will need to build these basic capabilities built in other languages such as C++, C# and provide bindings for other languages . We are aware of this need and any suggestions to address this are welcome On Sun, Nov 23, 2014 at 2:08 PM, Anurag Sharma anura...@gmail.com wrote: Solr interface is through REST API's which makes it easy to integrate with any platform and do binding any language. Each developer have to write common code to do the api bindings if using Solr in non java framework/platform. This overhead can be reduced by building client sdk's/libraries for popular languages and platforms e.g. - web: js, ruby, python - mobile: Objective C, Swift, C# - other: C++, Scala, perl, php Also, this can significantly reduce time to Solr on-boarding when using non java platform. Suggestions? -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
Is that the current plan? To contribute things like client list there? I am happy to do it, just wasn't sure if it then gets wiped out in the migration. 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 24 November 2014 at 11:01, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: FYI see https://wiki.apache.org/solr/IntegratingSolr for a list. This is a great use of the wiki. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Mon, Nov 24, 2014 at 10:35 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: Well, a start would be to actually have an up-to-date list of Solr clients. I have the list, if somebody knows where it should go (Ref Guide). I don't want to contribute this to WIKI as we are trying to get rid of it. Then somebody (Summer of Code project?) would derive from that a list of clients that are up-to-date (a very different story). This would require a high-level set of features that clients are expected to cover. I have some thinking around that I am happy to share in a rough form. I would also - as mentioned before - setup a mailing list for all the client developers to discuss new features in a common way. Do not think of this as a primarily code problem - think of it as a community consolidation and establishing clear interfaces to the downstream projects. 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 24 November 2014 at 10:24, Noble Paul noble.p...@gmail.com wrote: This has been a constant pain point for Solr. Java client is a first class client where it benefits from knowing the correct servers to communicate to because it is aware of the clusterstate. The java client also has the advantage of using the faster and compact binary format. We will need to build these basic capabilities built in other languages such as C++, C# and provide bindings for other languages . We are aware of this need and any suggestions to address this are welcome On Sun, Nov 23, 2014 at 2:08 PM, Anurag Sharma anura...@gmail.com wrote: Solr interface is through REST API's which makes it easy to integrate with any platform and do binding any language. Each developer have to write common code to do the api bindings if using Solr in non java framework/platform. This overhead can be reduced by building client sdk's/libraries for popular languages and platforms e.g. - web: js, ruby, python - mobile: Objective C, Swift, C# - other: C++, Scala, perl, php Also, this can significantly reduce time to Solr on-boarding when using non java platform. Suggestions? -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
On the wiki are two pages listing out projects that use Solr: http://wiki.apache.org/solr/SolrEcosystem http://wiki.apache.org/solr/IntegratingSolr I noticed that they have become stale and was going to update them. Maybe they could have more prominence in the Solr site? But keep them community driven since things change so quickly. Eric On Nov 24, 2014, at 10:35 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: Well, a start would be to actually have an up-to-date list of Solr clients. I have the list, if somebody knows where it should go (Ref Guide). I don't want to contribute this to WIKI as we are trying to get rid of it. Then somebody (Summer of Code project?) would derive from that a list of clients that are up-to-date (a very different story). This would require a high-level set of features that clients are expected to cover. I have some thinking around that I am happy to share in a rough form. I would also - as mentioned before - setup a mailing list for all the client developers to discuss new features in a common way. Do not think of this as a primarily code problem - think of it as a community consolidation and establishing clear interfaces to the downstream projects. 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 24 November 2014 at 10:24, Noble Paul noble.p...@gmail.com wrote: This has been a constant pain point for Solr. Java client is a first class client where it benefits from knowing the correct servers to communicate to because it is aware of the clusterstate. The java client also has the advantage of using the faster and compact binary format. We will need to build these basic capabilities built in other languages such as C++, C# and provide bindings for other languages . We are aware of this need and any suggestions to address this are welcome On Sun, Nov 23, 2014 at 2:08 PM, Anurag Sharma anura...@gmail.com wrote: Solr interface is through REST API's which makes it easy to integrate with any platform and do binding any language. Each developer have to write common code to do the api bindings if using Solr in non java framework/platform. This overhead can be reduced by building client sdk's/libraries for popular languages and platforms e.g. - web: js, ruby, python - mobile: Objective C, Swift, C# - other: C++, Scala, perl, php Also, this can significantly reduce time to Solr on-boarding when using non java platform. Suggestions? -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
They are super-stale 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. 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. 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 24 November 2014 at 11:26, Eric Pugh ep...@opensourceconnections.com wrote: On the wiki are two pages listing out projects that use Solr: http://wiki.apache.org/solr/SolrEcosystem http://wiki.apache.org/solr/IntegratingSolr I noticed that they have become stale and was going to update them. Maybe they could have more prominence in the Solr site? But keep them community driven since things change so quickly. Eric On Nov 24, 2014, at 10:35 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: Well, a start would be to actually have an up-to-date list of Solr clients. I have the list, if somebody knows where it should go (Ref Guide). I don't want to contribute this to WIKI as we are trying to get rid of it. Then somebody (Summer of Code project?) would derive from that a list of clients that are up-to-date (a very different story). This would require a high-level set of features that clients are expected to cover. I have some thinking around that I am happy to share in a rough form. I would also - as mentioned before - setup a mailing list for all the client developers to discuss new features in a common way. Do not think of this as a primarily code problem - think of it as a community consolidation and establishing clear interfaces to the downstream projects. 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 24 November 2014 at 10:24, Noble Paul noble.p...@gmail.com wrote: This has been a constant pain point for Solr. Java client is a first class client where it benefits from knowing the correct servers to communicate to because it is aware of the clusterstate. The java client also has the advantage of using the faster and compact binary format. We will need to build these basic capabilities built in other languages such as C++, C# and provide bindings for other languages . We are aware of this need and any suggestions to address this are welcome On Sun, Nov 23, 2014 at 2:08 PM, Anurag Sharma anura...@gmail.com wrote: Solr interface is through REST API's which makes it easy to integrate with any platform and do binding any language. Each developer have to write common code to do the api bindings if using Solr in non java framework/platform. This overhead can be reduced by building client sdk's/libraries for popular languages and platforms e.g. - web: js, ruby, python - mobile: Objective C, Swift, C# - other: C++, Scala, perl, php Also, this can significantly reduce time to Solr on-boarding when using non java platform. Suggestions? -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
