7 Aug 2001 rudybrian   » (Master)

I finally found a secure and scalable way of interfacing the C-language localizer and the Perl-based map applet CGI interface yesterday!

The cleanest way of doing this would be using perlxs but my initial attempts using this method were thwarted by a rash of unintelligible linker errors. They were most likely related to the TCX library which uses some signalling types not supported by the Perl API.

The next-best method involves adding Perl interface stubs to a native C-language localizer client via perlembed. The localizer client will be able to push variables onto the Perl stack and call Perl subroutines directly. The client will poll for goals or other client-side information. Because our CGI is not persistant (not running constantly) and (possibly) not running with the same user credentials, it must have some means of retreiving the variables. This is accomplished with the IPC::ShareLite module. This way when the CGI executes it can quickly pull the variables from shared memory and return them without hitting the file system or creating a measurable burden on the server regardless of the number of clients.

I did run into a problem though. Since IPC::ShareLite only understands strings and scalar data types, to store and retrieve the variables (as a hash) from the shared memory space, they must be Shareable::freeze()'ed first. For some reason, doing this discards the hash key, rendering the data unretreivable. This is probably a bug in the version of IPC::Shareable I have installed. I did a really kludgey workaround and was able to sucessfully pass data directly from a compiled C program to the Java map applet running in a browser window.

Slow progress is still progress ;)

Latest blog entries     Older blog entries

Share this page