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.


>>
>>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).


> 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.]


> 
> + 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.


> 
> + 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.



-- 
Peter Karman  .  http://peknet.com/  .  peter(at)not-real.peknet.com