proposed changes to RSiteSearch

Don't forget R wiki in the list.
Best,

Philippe
..............................................<?}))><........
 ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
 ) ) ) ) )   Mons-Hainaut University, Belgium
( ( ( ( (
..............................................................

Romain Francois wrote:

Jonathan Baron wrote:

After reading all this, I favor doing one of two things:

1. Put all the search stuff, including the proposed gmane function, in
   Spencer's new package but make it one of the default packages, like
   utils, etc., or,

2. Put everything in utils, including Spencer's new package and the
   gmane function.

I do not know enough to choose between these.
  

I would tend to prefer #1 so that the functionality can incubate in a 
separate package, and then when it is mature enough, we can make a 
call about what to do with it.

Something like this:
- a generic abstract function that sets up the interface to query a 
search engine.

- implementations of this, here are what I can think of:
+ jon's RSiteSearch for help pages
+ r graphical manuals
+ gmane, markmail for mail archives
+ classic help.search
+ R news (not clear how to do this right now)
+ vignettes (not clear how to do this right now)
+ JSS articles (not clear how to this right now)
+ FAQ (not clear how to this right now)
+ ... add your own by simply register your implementation

The point about having some sort of central generic function is that 
it can be responsible for asking all engines and bring all results 
back in a single format.

This somehow duplicates work I have been doing with the rsitesearch 
firefox extension, but doing it in R has several advantages.

This I think is enough design to be a separate package.

I am not sure what are the requirements for a package to be shipped 
with the distribution of R (QA, documentation, ...), but I am sure 
whoever steps me (maybe me) can make it compliant.

There is precedent for functionality that was in a package and was 
merged into utils afterwards (rcompgen), but I think it was included 
because this was necessary, don't think these search engines __have__ 
to be in utils.

On 05/07/09 14:42, spencerg wrote:
 

      1.  Whatever we do with the "RSiteSearch" function, it should 
still be available every time R starts.  If we put it in its own 
package, it should still be autoloaded with "base", "utils", 
"stats", etc.     

Good point.

 

      2.  Sundar indicated to me that, "if Jonathan would like to 
remove the search capability, it would be rather simple to move 
RSiteSearch to nabble" for the listserve archives.  The 
"RSiteSearch" function could be modified to combine that with a 
separate search of only the help pages on Jonathan's server.     

I do not understand "rather simple" at all.  For those who are
interested, I've put my notes on how to manage my site (which still
need a bit of revision, but this will give you some idea of what is
involved) in

http://finzi.psych.upenn.edu/~baron/notes.namazu.txt

The problem is that I have not found a way to automate this, so I
still spend several hours each month doing it by hand.  Too many
little glitches come up along the way, and the main problem is the
mailing lists.  Moreover, Namazu just doesn't work all that well for
mailing lists of this size, because of the page footers in each post.
(Now I remove them.  That was a bad idea.  But if we're going to get
rid of this anyway I will not take the time to figure out how to put
them back properly.)

Also, Liviu Androic argued that vignettes should be searchable
separately from help pages.  This makes sense, but I would strongly
prefer to move ahead on other changes and leave this until later.
The need for this sort of modification is what makes me favor option
#1 at the beginning (separate package) on the theory that it would be
easier for me to make changes than if it were part of utils, but I
don't know how this works.

So, if someone can make a decision about how to proceed, I'll do what
I can, as soon as I can.

Jon