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
