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
>>+ 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.
Or we could do simple aliasing with typeglobs to make it just a little
*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?
Plus Three, LP
Received on Wed Jul 6 07:50:42 2005