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: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
