>You need to look at SOAP::Lite, I think. That would be one way to >accomplish this. Since you don't really need to interact with a web >page, LWP probably isn't necessary. SOAP is web services (or you >could look at XML-RPC) and this is exactly the kind of problem it was I'll look into this as well. One thing I'd thought of is if lwp could grab the output of the script, ie the same stuff as the source code would be if you called it in a browser, that I could set the vars withh that.
If you went to www.domain.com/script.cgi?show=animal in a browser it would just output : monkey then I could grab that 'monkey' by just calling the same thing via lwp and using that $reply or whatever variable it was. I'm just not totally sure that's what lwp does I guess. >designed for. You have a generic "service" script somewher that >handles the database connectivity which exports an API for adding a >variable or retieving it. Additionally, SOAP is designed so that you >can secure the transaction so that not just any script to could add >things to your DB. Actaully the db script in question only does select statements. >If you are really sure you don't need security and the "genericness" >of SOAP, you might look at just setting up a simple TCP daemon that >listens for connections from your client scripts. This means you >would have to invent the higher level protocol yourself (parsing out >the requests from the data, formating your replies, etc). It also What I though about, as far as higher level >would be pretty insecure if you are using it over a network. >I have to admit that I haven't done any development with SOAP but I >know this is the kind of problem that it was invented for. >The other issue, though, is do you really want to abstract away the >DB connection stuff from each script. The reason to have all that Yes I definately do because the scripts that need to access the data will be in someone else's account on a different server that I have nothing to do with. So if they had access to any of the database info they might try something nasty. I'm more concerned with that than, say someone deciding to copy the data fetching script and using that to fetch the data for themselves because this particular data would be pretty much useless to anyone but the owner. But if they had some of the info they could replace the data with incorrect, vulgar, nothing, etcc... which in this case would be much worse. >present in each script is so that you don't have a huge gaping hole in >your DB access model. Perhaps if you abstracted your DB access into >an object that you 'use'd in all your scripts, you could get the >benefits of having all the db access stuff in just one place but still >have the actual security of only having no intermediaries between your >script that needs the DB info and the DB itself. >Hard to say what the best trade offs are. Yeah I know. >Hope this helps. I'm sure it will, thanks for your time.
