all physical handlers have been revisited so they could be reused to index any attachement in any module, and not only resources.

Physical handling extensino was tried with Adobe Search SDK. Although non GPL, there would be a provision for non standard SWF indexing, with sufficiant advertisment for user. Tim William might distribute this "not so free" pack with autoview.

Note a particular proceeding for setup that ought to be commented in doc :

When changing the list of allowed extensions (adding some extra extensions) will be created additional config keys to setup system command line, and an optional environment variable.

As I did not use Ajax nor Javascript for updating interatively the form, there is a need to first save the altered extensions list, and then go back to the setup form to have the additional parameters available.

This should be the case (tested on my dev 1.8.4) for SWF handling, where the lib should be added to <%%moodleroot%%>/lib as "swfconverters" subdirectory, and subsequently binded in the search setup screen using a command line such as "lib/swfconverters/windows/swf2html.exe" (Windows example - No env variable needed).

Note 2 : as Adobe Search libs should not be distributed along, all references to this lib pack is given where relevant as http://www.adobe.com/licensing/developer/ for ones who want to test. works fine.

Cheers.

Need finishing query side aspects of getting third-party modules outside of core search engine.

I am actually getting some stuff simpler, shooting out some useless constants.

HEAD will be patched with a new review soon.

I will integrate a contribution code that adds document type icon and a course reference within the result line.

Result set needs to be reworked when searching with a non connected status.

A tricky problem remains affecting search query performances :

The ideal would be that we only check access on a result page. But enabling or disabling access changes the result set length itself, and thus affects page size and boundaries in the list of initial results.

I'am searching now a suitable algorithm to optimize the result page construction, avoiding as far as we can testing access on unneeded material.

An implementation of caching search results for browsing from page to page was kicked off by Michael Campanis, but not fully implemented so it is not operative. The actual version does not cache results so has to test back all the primary result list for each query. This is obviously time and power consuming.

Caching results seems being a necessity.

Another approach I'am seeking for is to calculate and transmit to browser real offsets of page boundaries, so that a page is the result of searching the next page_size valid results ahead in premary results, wherever they are. This will still not resolve the issue of calculating the effective result set size, defining how many pages we have.

Cheers and some headakes foreseen.

Can you please post diff patches here for all proposed fixes in 1.9?

little time available, but here is an up to date full diff for /search

Next to come is the full diff for /blocks/search

The real nice thing would be to check what where Eloy's changes in HEAD (sure be few) and have both code synced unless those little changes (1.9 is MO the best code available among the branches).

All announced features are in, unless still extensively untested by now.

Other coming features, such as MNET search where not put in, as being on a very early stage of development (quite complicated, in fact, because revamping many xml_rpc code...)

Cheers.