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