Skip to main content.
home | support | download

Back to List Archive

RE: Anyone using the PHP module?

From: Bill Moseley <moseley(at)not-real.hank.org>
Date: Fri Oct 10 2003 - 21:12:53 GMT
On Fri, Oct 10, 2003 at 03:48:56PM -0500, Patrick O'Lone wrote:
> Bill,
> 
> > I don't know a think about PHP.  What's a "resource" vs. and 
> > object in PHP?
> 
> Well, a "PHP" resource is a handle to the "real" resource that would be
> created using the native C function. For example, in the SWISH-E C API,
> 
> SwishInit();
> 
> would return SW_HANDLE. Obviously, the PHP scripting language doesn't know
> what this is. What we do instead is register that SW_HANDLE as a resource in
> PHP and return a handle instance of that, so:

Ok, so it's basically a container that PHP knows how to deal with.  
Works the same in Perl, of course.

        handle = SwishInit( index_file_list );
        ST(0) = sv_newmortal();
        sv_setref_pv( ST(0), CLASS, (void *)handle );
        SwishSetRefPtr( handle, (void *)SvRV(ST(0)) );
        XSRETURN(1);

I get the handle (which is just void *), create a new Perl variable, and
then assign that pointer to that variable.  I also assign it a class.
In this case, the Perl structure contains the pointer to the swish
handle.

Perl's xs interface has typemaps which make it easy to work with the
handle, though:

void
SwishAbortLastError(self)
    SW_HANDLE self

That's all the "glue" needed to call the C API.  The typemap knows how to pull out the
"handle" from the Perl data structure.

Some things are more complicated, of course, but the Perl interface is
quite thin.


> > I wouldn't use efree() externally, and instead use the API.  
> > For example, to free a search object (search_close above) I 
> > it should use
> > 
> >   Free_Search_Object( search );
> > 
> > calling efree() directly would cause a memory leak.  For 
> > example, inside the search structure is the query string, 
> > sort parameters and -L limit parameters.
> 
> 
> He has to use efree() which is a PHP memory deallocation routine that wraps
> free(). The efree() routine performs memory management and prevents memory
> leaks from occuring. Of course, you might be referring to native calls to
> malloc() within the SWISH-E internals that would get messed up with calls to
> PHP's emalloc() and efree() routines. 

Ah, ok.  I thought that was calling swish-e's internal efree() call.


>  
> > > 
> > > Is there going to be a SWISH-E API for indexing as well?
> > 
> > Considering that indexing is a single command operation, I 
> > don't really see where an API would help.  That's what 
> > "system()" is for.
> 
> Well, I'm talking about an API where I could open an index and supply my own
> XML document, something like:
> 
> hIndex = swishe_index_open("index", "swish-e.conf");
> swishe_index_capture(hIndex, "<?xml
> ?><docid>1</docid><doctext>stuff</doctext>");
> swishe_index_close(hIndex);
> 
> Basically, the API would allow my application to provide the text to the
> indexing engine directly and allow me to supply documents by "writing" to
> the indexer inside my application, avoiding exec() or system(). This allows
> an application developer to more tightly integrate SWISH-E's powerful search
> API.

The fork will be insignificant compared to the expense of indexing.

Anyway, in Perl:

open SWISH, '|swish-e -c config -S prog -i stdin';
for my $document ( @list_of_docs ) {
   print SWISH format( $document );
}
close SWISH || die;

Even with incremental indexing adding a file requires rebuilding all the
internal sort tables, so it's not a simple operation -- it's not like
inserting a record into a database (unfortunately).


-- 
Bill Moseley
moseley@hank.org
Received on Fri Oct 10 21:16:56 2003