To elaborate a little on bitingduck's reply: run a script every 10 minutes to collect the data and write it to a database. It's likely that DBD::SQLite wrapped up by DBI is all you need. If you've not dealt with databases already take a look at RFC: Databases made easy to get started.

So: you create two scripts. The first one does whatever work is required to collect the data and write it to the database and is probably run as a cron job or similar. The second script is run by users to get the latest version of the data from the database.

It sounds like you already described your solution. Is the only thing missing a file (or maybe a database, depending on what you really want to display for users) where the current version of the data gets stored so that it can be pulled up for each user on demand? And maybe a cron job to update the data every 10 minutes automatically (it wasn't clear from your description).

Or is there more to the problem than this?

I would start by agreeing that this is an excellent use case for a database under most conceivable operating conditions -- and SQLite will very likely serve you well here.

That said, if you really want to keep the script-in-memory-hash thing going for some reason, and really do want to simply feed the data from your in-memory hash to all comers, you have your work cut out for you:

• You need to establish a communication method, such as a socket listener or some other kind of web service;
• You need to establish and deploy a data transmission packetization system, such as XML, SOAP, REST, JSON, etc.;
• You have to iterate across your hash to put the information out on the service, with a sister routine to decode that back into a hash on the other end for the client.

Now -- that would be a fun project, and you'd learn a ton of potentially useful stuff. But it will take time, and time is money.

You may have to invest time to learn DBIand  SQLite, but you don't have to build much enginery to make it work, so I would hazard a guess that it will take 1-4% of the effort needed to build all the machinery for the service-communication approach.

Not to mention that if you build your own framework, you will also then need to maintain it.

Unless you have a fairly strong reason to the contrary, I think the combination of SQLiteand DBIis going to be your friend on this one.

Agreed, it might be fun but it would be certainly over-engineered. I would generally think constructs like that should only be employed when you REALLY can't do without real time data.

"all users are on the same box" <- big clue :)

First script writes to a file (atomically) using, perhaps, Storable. Any user can then retrieve it whenever they want.