Instead of using a webserver you can also consider writing your own little client-server system. This might be easier to start with, and a nice way to learn about it.

All players get a client program that communicates via a socket to a sever program. Sockets are pretty easy to program (for examples see the perl cook book). The server program keeps track of the score and the cards. The client program displays everything (you could use PerlTk for that) and accepts the moves and bets. The advantage of writing it yourself is that you can make it as interactive as you like as you control the communication protocol.

A drawback would be that your friend have to install Perl too... but then again that is not a real drawback but rather a chance to learn a very enjoyable language.

And: If you want to get a server up and running quickly, have a look at Netserver::Generic. It'd leave you lots of time to play with the client code.

Here at perlmonks, also see the thread at Poker Odds for Texas Holdem.

On Perl Monks -
CGI/Network Tutorial.
At CPAN
CGI.pm

Books -
For a list of Books have a look at Perl Monks Reviews

I look forward to seeing your product.
Neil

Now to get to your question. I originally wanted to do it via CGI, but you run into one big problem...CGI is a stateless protocol, so you will have to store all the sessions in a database of some sort, send out alot of hidden fields to maintain state of the users, and deal with the fact that you will need to force an update to all the users, that may require javascript ? Otherwise, the players won't know when the other players have played, unless they click an "update" button. So that is your big problem with using CGI.

Now I just decided that using TCP sockets was an easier way to go. You make a perl server listening on some port, and have your clients connect to it. I'm using Tk for the clients. The benefits of using TCP are: it maintains state, the server can send out data to the clients for updates, automatically; and it also allows for a little real-time chat between players.

So consider TCP for realtime games, it actually is easier than CGI, (once you learn a bit about sockets, and some Tk for the clients)

But you might want to check out OpenThought too which I haven't tried although it has always seemed neat, in that a running perl cgi application can push data to a user's homepage through javascript quickly, so users don't have to wait for a whole page to reload.

Also more advanced, but if you want more of a client application instead of a web page, check out WxPerl which is a Perl interface to the cross-platform GUI toolkit WxWidgets. But you can do pictures, sound, and javascript animation with ordinary web pages so wxperl is probably not what you need now.

It certainly is possible to accept and display input to different users at the same time, but your application needs a way to always know the state of the game. This requires some kind of persistence mechanism. You could write the information to a text file but then you would have to write code (or get a module) to deal with several people trying to access it at once. More likely you would be using a database, or maybe a "tied hash" (a data structure that is automatically saved to disk when it is changed). Or you cuold just use a hash that is stored in a (IPC) shared memory cache. These storage modules will be accessed every time someone does something to change the state of the game (i.e. makes a move).

In Perl if you are very new to it, the keywords are "TIMTOWTDI" (There Is More Than One Way To Do It), and "laziness" which is seen as a virtue. In this case, laziness means find useful modules from the CPAN (they can be automatically installed for you too) which you know already work, so you can focus more on the presentation and game logic.

If you use a database in Perl you usually use the DBI module (see search.cpan.org) in which case you might like Class::DBI, which simplifies it with an object interface. But the plain DBI module provides ways to grab a whole table or row into a perl data structure (a hash or array).

Finally as for logging in users, a simple CGI parameter is enough for you to store the name of the user probably, but a system that would be a little harder to cheat on would probably use something like the module CGI::Session (or I use Application::CGI::Session I think) to create a session for each user in the database when they log in. This is more than you want to get into now.

Wny not start really small and simple, and then grow from there? You are sure to learn a lot!