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, [email protected] <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> > 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: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
