Solr 1.2

[Ryan McKinley <ry...@gmail.com>]

I have finished adding the major things I wanted in solr1.2.  I think 
everything followed the http://wiki.apache.org/solr/CommitPolicy except 
the unlisted one that its nice to keep the time/changes ratio long 
enough that you can grock whats going on through osmosis ;)

Other patches on the 'popular' list that I know about and think are 
stable enough to consider:
   SOLR-176
   SOLR-142 (if it can/should be added independent of jsp integration)

It is maybe worth waiting for something like SOLR-85 and integrating the 
admin handlers with the admin jsp, but I won't have much time till after 
the 10th.

- - - - -

Open trivial questions:

1. should we remove IndexInfoRequestHandler.java?  It is a subset of the 
LukeRequestHandler, but IIRC it was implemented for the internet archive.

2. Should we move DisMaxRequestHandler.java and 
StandardRequestHandler.java to o.a.s.handler -- leaving a @Deprecated 
class in its place.  This would give people a way to extend these 
classes and gives us a way to clean up o.a.s.request in future releases?

3. Can you take a look at the output from o.a.s.handler.admin.* and make 
sure the output could be styled with xslt.  Eric, can you make sure it 
is using SimpleOrderedMap wherever appropriate for flare?


Regarding the logo... I asked both Juan and Nick to take another look at 
the logo - with an eye for something "professional"; But I don't think 
we should rush it for solr1.2 unless something magically appears.

good good
ryan

Re: Solr 1.2

[Ryan McKinley <ry...@gmail.com>]

Erik Hatcher wrote:
> 
> On Apr 29, 2007, at 7:39 PM, Ryan McKinley wrote:
>> Open trivial questions:
>>
>> 1. should we remove IndexInfoRequestHandler.java?  It is a subset of 
>> the LukeRequestHandler, but IIRC it was implemented for the internet 
>> archive.
> 
> I implemented that request handler for Flare, so it can introspect on 
> the field names to show facets for *_facet fields, and search on the 
> *_text fields.  So yeah, we can deprecate IndexInfoRequestHandler in 
> lieu of cool hand Luke.
> 

Excellent.  I deprecated the class, but I'll let you delete the file if 
you are no longer using it.  (It was added since 1.1 so unless we want 
to support it, it should probably go)


>> 3. Can you take a look at the output from o.a.s.handler.admin.* and 
>> make sure the output could be styled with xslt.  Eric, can you make 
>> sure it is using SimpleOrderedMap wherever appropriate for flare?
> 
> It may be a while before I get a chance to take a good look at this.  
> I'm sure any data being returned is fine to read with solr-ruby, it just 
> might be more awkward to navigate.  So not a huge deal for me either way.
> 

ok, i just wanted to make sure I'm not doing something awful -- I don't 
think i am.

Re: Solr 1.2

[Erik Hatcher <er...@ehatchersolutions.com>]

On Apr 29, 2007, at 7:39 PM, Ryan McKinley wrote:
> Open trivial questions:
>
> 1. should we remove IndexInfoRequestHandler.java?  It is a subset  
> of the LukeRequestHandler, but IIRC it was implemented for the  
> internet archive.

I implemented that request handler for Flare, so it can introspect on  
the field names to show facets for *_facet fields, and search on the  
*_text fields.  So yeah, we can deprecate IndexInfoRequestHandler in  
lieu of cool hand Luke.

> 3. Can you take a look at the output from o.a.s.handler.admin.* and  
> make sure the output could be styled with xslt.  Eric, can you make  
> sure it is using SimpleOrderedMap wherever appropriate for flare?

It may be a while before I get a chance to take a good look at this.   
I'm sure any data being returned is fine to read with solr-ruby, it  
just might be more awkward to navigate.  So not a huge deal for me  
either way.

	Erik