Practical Internet Groupware

Replicating Code

We centralize services in part to cut down on the administrative burden of maintaining distributed services. The zero-footprint, no-install nature of web-based software is one of its most compelling features. But it’s not appropriate to centralize everything. Some services ought to run locally because the network connection is intermittent, or because it’s more efficient to connect to local resources, or simply because they’re personal rather than shared. In these cases code needs to be not merely mobile, like Java, but persistent, like ActiveX. What happens, in a distributed network of peers, when you need to update not only the data stored on each node, but the methods that operate on that data? The dhttp environment enables a simple solution to this problem. Example 15.9 shows the public engine function do_engine_update_sub( ), which enables a dhttp node to update one of its plug-ins in situ and on the fly.

Example 15-9. dhttp Support for Code Replication

                  
                   sub do_engine_update_sub { my ($args) = @_; my ($argref) = &Engine::PrivUtils::getArgs($args); my ($app) = &Engine::PrivUtils::unescape($$argref{app}); my ($subname) = &Engine::PrivUtils::unescape($$argref{subname}); my ($subcode) = &Engine::PrivUtils::unescape($$argref{subcode}); my ($module) = ''; my ($found) = 0; open(F,"$main::root/Apps/$app.pm") or $main::debug && warn "cannot open $main::root/Apps/$app.pm"; while (<F>) { if ( m#^1;# ) # module ends with 1; { if (! $found ) # if target sub not yet found ...