Skip to main content.
home | support | download

Back to List Archive

Re: SWISH::* and CPAN

From: Michael Peters <mpeters(at)not-real.plusthree.com>
Date: Wed Jul 06 2005 - 14:50:21 GMT
Peter Karman wrote:
> 
> Michael Peters scribbled on 7/5/05 2:41 PM:
> 
>>Would I need to get cvs access to do this work? Or should it be separate
>>from swish-e? I think I would prefer that it stay in the same cvs repo
>>since I'm not writing it, just 'cleaning up' and the bulk of the
>>knowledge about it is not in my head.
> 
> Since SWISH::API changes about as often as Swish-e gets released (which is about 
> 1-2 times a year, at current pace), it might make sense to just keep a copy of 
> the Perl module on CPAN for redundant (and easy perl user) availability. 
> Wouldn't be too much overhead keeping the versions in sync with the current 
> [in]frequent releases.

That makes perfect sense. This would still allow for more frequent
releases of the SWISH::API module without needed a new release of
swish-e should that ever be necessary.

>>>Maybe we could put Peter's buildswishe.pl script in the SWISH::API
>>>distribution and then it could automatically install swish-e...
>>
>>That's an idea as well, however I do have my doubts about it. Most other
>>perl packages on CPAN which rely on external libraries don't try to
>>install those libraries (eg, GD, DBD::mysql, etc). It might be asking
>>for trouble if our attempt at an install borks something system wide.
> 
> I agree; maybe it should be in the CPAN package as an add-on, same way that it 
> is with the swish-e cvs right now. It's there if someone wanted it, but you 
> would have to run it manually (i.e., not a part of the API build via cpan).

Maybe just a brief doc mention and let CPAN install it as well?

>>Some other thoughts I have on the migration to CPAN. Please
>>critique/comment as you see fit.
>>
>>+ Bundle the other SWISH::* modules together (eg, SWISH::ParseQuery,
>>SWISH::PhraseHighlight, etc) so that they can then be used outside of
>>the search/swish.cgi scripts.
> 
> I'm not sure how useful those would be outside of the scripts. There are query 
> parsing methods in SWISH::API that call the real C function(s); the highlighting 
> (I can hear Bill groan when I bring it up...) is fairly Swish-specific. [full 
> disclosure: I wrote SWISH::HiLiter which can do all the same kinds of 
> highlighting as the SWISH::*Highlight modules in the distrib do.]

Wow, I didn't even know that the SWISH::HiLiter module existed. I was
thinking about ripping out the highlighting stuff from the other SWISH::
modules myself and now I don't have to do that :)

I do have a feature request for SWISH::HiLiter, but I'll make that a
separate email.

>>+ change the namespace from 'SWISH' to 'SWISHE'.
> 
> ugh. while 'purer' to do it that way, there's a lot of legacy stuff, and other 
> SWISH packages already out there by other developers (SWISH::API::Remote, 
> SWISH::HiLiter, etc.) I don't think we should change the namespace.

Ok.

>>+ redo the method names so that they are more 'perlish'. eg, change
>>"Query" to "query", "New_Search_Object" to "new_search_object", etc. Not
>>really important, just more in line with the common perl style (also
>>more like Bill's previous SWISH module on CPAN).
> 
> might be easier [better?] to just make aliases. The names right now correspond 
> to the C library names, which for developers' sake is nice when grep'ing, etc.
> 
> But perlish is good. Something like:
> 
> sub new_search_object
> {
>      return New_Search_Object(@_);
> }
> 
> might suffice? That would also keep legacy code from breaking.

Or we could do simple aliasing with typeglobs to make it just a little
bit faster.

*new_search_object = *New_Search_Object;

So do I need cvs access or should I just do a checkout as anonymous and
then submit patches?

-- 
Michael Peters
Developer
Plus Three, LP
Received on Wed Jul 6 07:50:42 2005