In a situation like this, I have a couple of questions, which would affect my recommendations --

1. Are you the user of this, or are the users reasonably technical savvy and trustworthy?
2. Is there a single specific client system that is connecting, or multiple client systems?
3. What is the security required by the information being passed, and the security already in the database?
4. Who controls DHCP?
5. Is the current UI web based?

If I were going to be the only user, or the users were people that I trusted to follow directions, I'd probably use an SSH tunnel, and place a wrapper around the connection to start the tunnel. You could also use a VPN, or requiring port knocking before the server allows access

If there needed to be multiple clients that needed to connect, I might place a system on the network that had the necessary permissions to connect to the database, but acted as a gateway / bastion host.

If you know the folks who are controlling DHCP, I'd look into setting up a smaller IP pool for the systems that need to connect.

If the security requirements are really low, I probably wouldn't worry about things too much, and just open up the network to the subnet.

If the plan for the UI is web based, it doesn't seem like it's a signfiicant stretch to send updates via HTTP, but if it's not, you may be introducing extra unnecessay complexity. (and opening up unnecessary ports if the server doesn't already have an HTTP service exposed)

But, to answer your questions directly:

Is this insane?

I think it's probably more effort than it's worth, however, you can also use the proxy to perform extra error checking and/or access control, if you needed to.

One of my db elements is a blob generated by mod Storable. Can I send this data directly via http POST or GET without getting involved in all kinds of MIME complications?

So long as it's all properly escaped, you should be fine. If you're doing queries, you can use GET, but for any sort of request that modifies data, you should use POST, which should not be re-executed by a client without prompting, and won't be cached.

I personally wouldn't use CGI to pass my data, but would be more likely to use SOAP, which was basically made for these sorts of operations.

Many thanks to everybody who replied to this thread, especially jhourcle who pointed out that I should be using SOAP for this.

The public nameserver idea was a good one, but alas my ISP required an IP address for external hosts.

So I used SOAP to take the db record on the client side, stick it into a data structure, send that over to ther server, recollect the data structure on the server side, then put it into MySQL over there. It works great.

Here is the code that does the job, in case anyone else can use it. In both cases it assumes that you supply a sub that converts the database record to/from a data structure and returns it to the client/server.

Keep yer stick on the ice...Steve

Client:

#!/usr/bin/perl -w
use strict;
use SOAP::Transport::HTTP;


sub sendthread {
    my $id = shift;
    my $reply;
    my $servermsg;
    my $data = getfromdb($id);
    my $server = SOAP::Lite                                           
+  
      -> uri('http://www.soaplite.com/Storeit')                       
+                      
      -> proxy('http://your.ip.net/cgi-bin/soapserver.cgi', timeout =>
+ 30);
    eval { $servermsg = $server->store($id,$data); };    
    if ($@) { # eval error
        $reply = $@;
    }
    elsif ($servermsg->fault) { # server fault
       $reply = join ', ', $servermsg->faultcode, $servermsg->faultstr
+ing, $servermsg->faultdetail;
    }
    else { # everything OK
        $reply = $servermsg->result();
    }
    return $reply;
}
[download]

soapserver.cgi

#!/usr/bin/perl -w
use strict;
use SOAP::Transport::HTTP;

SOAP::Transport::HTTP::CGI   
  -> dispatch_to('Storeit')     
  -> handle;

package Storeit;

sub store {                     
  my ($class,$id,$data) = @_;
  my $response = storetodb($id,$data);
  return $response;
}
[download]

That means nstore_fd instead of store_fd. You may get away not doing this if the clients are always the same architechture, but this is good practice and when you next have to port, e.g., to a Mac, you will have one less thing to puzzle about.

(Despite the name "network order", this advice is also applicable to applications that serialize data to disk. Sometimes you want to move a store to another machine too.)

I have indeed developed byte order problems, but am not sure how to fix. The windoze client gets the blob, which was generated with freeze rather than store, and sends it using SOAP. The SOAP server gets this and stores it OK, but when I try to retrieve and thaw the blob, I get error "Byte order is not compatible at blib/lib/Storable.pm"

Is this fixable by transforming the frozen blob before sending?

Can you nstore/retreive rather than freeze/thaw? Seems likely a protocol designed for memory use won't tansport well (freeze/thaw).

---

DWIM is Perl's answer to Gödel