incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Arnold <jer...@possiblyfaulty.com>
Subject Re: Droids as a standalone service
Date Fri, 04 Mar 2011 17:36:15 GMT
Thanks for the feedback Richard and Bertil. It seems like droids is
about as close a fit as I'm going to be able to find for my use case.

Richard, I'll likely start submitting patches this weekend to clean
everything up so the code base can be a bit more consistent. Thanks
for the feedback.

On Thu, Mar 3, 2011 at 4:49 AM, Richard Frovarp <rfrovarp@apache.org> wrote:
> On 03/02/2011 12:21 PM, Jeremy Arnold wrote:
> [snip]
>>
>> I'm interested in having a standalone searching/crawling service so I
>> can have 1 application hosting the searching and indexing used by many
>> different custom apps. I would like to have the option to use Solr or
>> elasticsearch for indexing/searching. I've been working with elastic
>> search for the past few days and am growing very fond of the
>> flexibility it provides. I'm also a sucker for JSON over HTTP
>> services. I need to be able to start crawls for both a filesystem and
>> webpages from within my custom webapp, or have the crawls run at
>> scheduled times. Those crawls then need to be indexed. I also need to
>> have the ability to integrate my own content handlers so I can specify
>> how certain pieces of content are indexed (e.g., custom PDF metadata).
>> I also need to be able to easily add or remove items in an index from
>> within my custom app, as well as the obvious updating items in an
>> index.
>
> I use Droids for something similar to this. I'm going against Solr and Derby
> to be able to quickly handle updates and a few other things. I am also
> handling different content with different handlers.
>
> [snip]
>>
>> acceptable counterpart to the existing droids-solr module. I would
>> also like to take on the task of bringing a lot more consistency to
>> the code base (e.g., commenting, code consistency). I'm just a bit
>> concerned about taking on such a large task and submitting it as a
>> patch. I also see a few places where testing would be beneficial and
>> do not mind attacking that as well, I just don't want to waste time
>> testing things that may be going away in the future.
>>
>
> I would suggest not doing it as a large task. Do it one or two classes at a
> time. If you submit javadoc patches in small chunks, I can make sure they
> get added in a reasonable time. Consistancy would also be a good thing to do
> in small chunks.
>

Mime
View raw message