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]

Reply via email to