Edit: Do keep in moind however that timer driven code on the server side is a necessary evil with the accent on evil. Overuse of this facility is the fastest way to end up bogging down your servers. If at all reasonable, it is better to have your server acting as an event driven processor of client events then generatring its own off a heartbeat. Clients *should* have central "game loops". Servers should not.
Jeff, for a persistent world game there may be events you want to have happening in the background which keep the world dynamic but are not a direct part of a player's actions. The basic game model I've referenced in other recent threads is a pirate-based game with you travelling the Carribien. A weather system is a key example of something that is global to the game world, should be completely server driven, and has direct impact on all clients ( and many other game events ). If a tropical storm builds up and moves west thru the region it will damage port cities, disrupt trade, and threaten the PCs. After the storm as passed and impact dertermined, some ports may be very bad places to trade while they rebuild, or they may have an increase in thier need for certain trade goods during that time. And how one port is impacted by the storm would have an economic impact on other near by ports that they trade with, even if those ports are not directly damaged ( the price of rum goes up if the major supplier for that area is devestated ).
If I'm understanding correctly, you are suggesting not using a traditional game loop on the server and keeping the game design event driven. If that's the case, in order to handle something like what I descirbed above ( and perhaps a dynamic economic model similar to what was brought up recently in another SGS thread ) would you suggest running an external service for these complex global systems? It could either provides events to the SGS as if it was a client or expose an interface for the SGS to querry ( like a basic J2EE web service ). In this example it would handle modeling the weather, impacting the port location, and tracking the rebuilding progress. If a player visits the port the SGS would send a request for current status to the service and use that information to generate the actual port objects.
It just sounds a bit counter intuitive to have to move something like this outside of the rest of the game server. The scaling capability and likely co-locating business model of the SGS is a major draw for me since I really will be starting small, but hope to grow. If I have to isolate a chunk of my "world" outside of the SGS and take on the questions of managing that service seperately it really impacts the ROI.
Of course, if I'm way off base, please let me know...