You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Matthias Epheser <ma...@indoqa.com> on 2009/06/25 17:42:02 UTC
[Fwd: Re: Time to rationalize SolrJS Docs???]
Re: [Fwd: Re: Time to rationalize SolrJS Docs???]
Posted by Eric Pugh <ep...@opensourceconnections.com>.
Avlesh,
I think if you are looking at steps, then Matthias has reasonable
layed out where to begin! I am actually out of town till end of next
week, so if you want to take the first crack, I'd be happy to review.
Apache is a "do-it-ocracy", so dig in!
I am actually currently using the solrstuff version of SolrJS, and
need to port to what is in contrib, so I can start testing that out.
Eric
On Jun 26, 2009, at 6:58 AM, Matthias Epheser wrote:
> Avlesh Singh schrieb:
>> I am ready to extend my helping hand Eric and Matthias for fixing
>> the docs
>> and the js-code base (if need be).
>> I have recently started using SolrJS and I feel that this contrib
>> is unable
>> to keep pace with enhancements in Solr.
>>
> I'm not up to date to severe api changes in current trunk. I think
> the main goals concerning maintainance, alongside implementing new
> widgets if someone has the practical need for them, should be (in
> that order):
>
> 1) Assure that all "base classes" that do the actuall http
> communication to solr are doing fine. (This should be no problem as
> the basic HTTP API doesn't change)
> 2) Keeping simple demo widgets for basic needs like facets etc.
> working.
> 3) Improve and organize docs according to user feedback
> 4) Implement demo widgets for NEW solr features or still uncovered
> features
> 5) Implement real world widgets (eg using third party libs like
> google maps) and share them
>
> I think of solrjs as a basic framework that encapsulates the
> communication to a solr backend ("best practices for solr and
> javascript"). The example widgets should be an introduction and
> sample code for people developing real world applications. Every
> project requires things (even slightly) different, eg. proxy servlet
> between client and solr, different user interface guidelines etc.
> With solrjs, there is a "basecamp" you can start from.
>
> I think 1) and 2) are still okay, 3) is discussed in this thread
>
> 4) and 5) will grow naturally when people using it and solving real
> world problems with solrjs
>
>
> Do these thoughts make sense for the community?
>
>
> regards,
> matthias
>> I would have been an author, if not a programmer. Lemme know what
>> all to
>> write about.
>>
>> Cheers
>> Avlesh
>>
>> On Thu, Jun 25, 2009 at 9:12 PM, Matthias Epheser <
>> matthias.epheser@indoqa.com> wrote:
>>
>>
>>> Eric Pugh schrieb:
>>>
>>>
>>>> Hi all,
>>>>
>>>>
>>> hi there
>>>
>>>
>>>> I started to create a bug for this, but thought I would just post
>>>> to the
>>>> mailing list. I've been using SolrJS for a while from
>>>> http://solrjs.solrstuff.org/, however from my conversations with
>>>> Matthias, the plan is to move to the Solr JavaScript contrib
>>>> module being
>>>> the master, and indeed my typo patch was applied there!
>>>>
>>>>
>>> great
>>>
>>>
>>>> So, the docs at http://solrjs.solrstuff.org/ don't reflect the
>>>> migration
>>>> into Solr, and that is something Matthias will have to fix I
>>>> assume.
>>>> However, we don't list SolrJS on the homepage under
>>>> http://wiki.apache.org/solr/ under Solr Clients, and the wiki
>>>> page at
>>>> http://wiki.apache.org/solr/SolrJS is confusing.
>>>>
>>>>
>>>> I am happy to clean up the docs a bit, and point to the contrib/
>>>> javascript
>>>> as the correct version. I just thought I would run it by the list
>>>> first for
>>>> confirmation that it should be done!
>>>>
>>>>
>>> That would be nice. As I'm stuck in non-javascript projetcs right
>>> now,
>>> there are no "new features" coming from me right now. It's also
>>> possible I
>>> missed sone questions on the mailinglist. But if there are
>>> concrete needs
>>> and questions that can be served by me, just point to me and I'm
>>> willing to
>>> help.
>>>
>>>
>>>> Also, isn't SolrJS really a client versus a contrib? Seems like
>>>> it should
>>>> be in ./clients/javascript along with the Ruby and Python clients
>>>> in source
>>>> control?
>>>>
>>>>
>>> Logically, it should be a client. I suppose there are some
>>> infrastructure
>>> issues (using third party libs for examples etc.) that lead to
>>> "contrib".
>>> Correct me if i'm wrong...
>>>
>>>
>>> Overall i'm glad to hear that there is still interest in teh
>>> technology..
>>>
>>> regards,
>>> matthias
>>>
>>>
>>>
>>>> Eric
>>>>
>>>> -----------------------------------------------------
>>>> Eric Pugh | Principal | OpenSource Connections, LLC |
>>>> 434.466.1467 |
>>>> http://www.opensourceconnections.com
>>>> Free/Busy: http://tinyurl.com/eric-cal
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
-----------------------------------------------------
Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com
Free/Busy: http://tinyurl.com/eric-cal
Re: [Fwd: Re: Time to rationalize SolrJS Docs???]
Posted by Matthias Epheser <ma...@indoqa.com>.
Avlesh Singh schrieb:
> I am ready to extend my helping hand Eric and Matthias for fixing the docs
> and the js-code base (if need be).
> I have recently started using SolrJS and I feel that this contrib is unable
> to keep pace with enhancements in Solr.
>
I'm not up to date to severe api changes in current trunk. I think the
main goals concerning maintainance, alongside implementing new widgets
if someone has the practical need for them, should be (in that order):
1) Assure that all "base classes" that do the actuall http communication
to solr are doing fine. (This should be no problem as the basic HTTP API
doesn't change)
2) Keeping simple demo widgets for basic needs like facets etc. working.
3) Improve and organize docs according to user feedback
4) Implement demo widgets for NEW solr features or still uncovered features
5) Implement real world widgets (eg using third party libs like google
maps) and share them
I think of solrjs as a basic framework that encapsulates the
communication to a solr backend ("best practices for solr and
javascript"). The example widgets should be an introduction and sample
code for people developing real world applications. Every project
requires things (even slightly) different, eg. proxy servlet between
client and solr, different user interface guidelines etc. With solrjs,
there is a "basecamp" you can start from.
I think 1) and 2) are still okay, 3) is discussed in this thread
4) and 5) will grow naturally when people using it and solving real
world problems with solrjs
Do these thoughts make sense for the community?
regards,
matthias
> I would have been an author, if not a programmer. Lemme know what all to
> write about.
>
> Cheers
> Avlesh
>
> On Thu, Jun 25, 2009 at 9:12 PM, Matthias Epheser <
> matthias.epheser@indoqa.com> wrote:
>
>
>> Eric Pugh schrieb:
>>
>>
>>> Hi all,
>>>
>>>
>> hi there
>>
>>
>>> I started to create a bug for this, but thought I would just post to the
>>> mailing list. I've been using SolrJS for a while from
>>> http://solrjs.solrstuff.org/, however from my conversations with
>>> Matthias, the plan is to move to the Solr JavaScript contrib module being
>>> the master, and indeed my typo patch was applied there!
>>>
>>>
>> great
>>
>>
>>> So, the docs at http://solrjs.solrstuff.org/ don't reflect the migration
>>> into Solr, and that is something Matthias will have to fix I assume.
>>> However, we don't list SolrJS on the homepage under
>>> http://wiki.apache.org/solr/ under Solr Clients, and the wiki page at
>>> http://wiki.apache.org/solr/SolrJS is confusing.
>>>
>>>
>>> I am happy to clean up the docs a bit, and point to the contrib/javascript
>>> as the correct version. I just thought I would run it by the list first for
>>> confirmation that it should be done!
>>>
>>>
>> That would be nice. As I'm stuck in non-javascript projetcs right now,
>> there are no "new features" coming from me right now. It's also possible I
>> missed sone questions on the mailinglist. But if there are concrete needs
>> and questions that can be served by me, just point to me and I'm willing to
>> help.
>>
>>
>>> Also, isn't SolrJS really a client versus a contrib? Seems like it should
>>> be in ./clients/javascript along with the Ruby and Python clients in source
>>> control?
>>>
>>>
>> Logically, it should be a client. I suppose there are some infrastructure
>> issues (using third party libs for examples etc.) that lead to "contrib".
>> Correct me if i'm wrong...
>>
>>
>> Overall i'm glad to hear that there is still interest in teh technology..
>>
>> regards,
>> matthias
>>
>>
>>
>>> Eric
>>>
>>> -----------------------------------------------------
>>> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 |
>>> http://www.opensourceconnections.com
>>> Free/Busy: http://tinyurl.com/eric-cal
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: [Fwd: Re: Time to rationalize SolrJS Docs???]
Posted by Avlesh Singh <av...@gmail.com>.
I am ready to extend my helping hand Eric and Matthias for fixing the docs
and the js-code base (if need be).
I have recently started using SolrJS and I feel that this contrib is unable
to keep pace with enhancements in Solr.
I would have been an author, if not a programmer. Lemme know what all to
write about.
Cheers
Avlesh
On Thu, Jun 25, 2009 at 9:12 PM, Matthias Epheser <
matthias.epheser@indoqa.com> wrote:
>
>
> Eric Pugh schrieb:
>
>> Hi all,
>>
> hi there
>
>>
>> I started to create a bug for this, but thought I would just post to the
>> mailing list. I've been using SolrJS for a while from
>> http://solrjs.solrstuff.org/, however from my conversations with
>> Matthias, the plan is to move to the Solr JavaScript contrib module being
>> the master, and indeed my typo patch was applied there!
>>
> great
>
>>
>> So, the docs at http://solrjs.solrstuff.org/ don't reflect the migration
>> into Solr, and that is something Matthias will have to fix I assume.
>> However, we don't list SolrJS on the homepage under
>> http://wiki.apache.org/solr/ under Solr Clients, and the wiki page at
>> http://wiki.apache.org/solr/SolrJS is confusing.
>>
>>
>> I am happy to clean up the docs a bit, and point to the contrib/javascript
>> as the correct version. I just thought I would run it by the list first for
>> confirmation that it should be done!
>>
> That would be nice. As I'm stuck in non-javascript projetcs right now,
> there are no "new features" coming from me right now. It's also possible I
> missed sone questions on the mailinglist. But if there are concrete needs
> and questions that can be served by me, just point to me and I'm willing to
> help.
>
>>
>> Also, isn't SolrJS really a client versus a contrib? Seems like it should
>> be in ./clients/javascript along with the Ruby and Python clients in source
>> control?
>>
> Logically, it should be a client. I suppose there are some infrastructure
> issues (using third party libs for examples etc.) that lead to "contrib".
> Correct me if i'm wrong...
>
>
> Overall i'm glad to hear that there is still interest in teh technology..
>
> regards,
> matthias
>
>
>> Eric
>>
>> -----------------------------------------------------
>> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com
>> Free/Busy: http://tinyurl.com/eric-cal
>>
>>
>>
>>
>>
>
>
>