conclusion pymailcgi versus pymailgui besides illustrating larger cgi applications in generalthe pymailgui and pymailcgi examples were chosen for this book on purpose to underscore some of the trade-offs you run into when building applications to run on the web pymailgui and pymailcgi do roughly the same things but are radically different in implementationpymailgui this is traditional "desktopuser-interface programit runs entirely on the local machinecalls out to an in-process gui api library to implement interfacesand talks to the internet through sockets only when it has to ( to load or send email on demanduser requests are routed immediately to callback handler method functions running locally and in-processwith shared variables and memory that automatically retain state between requests as mentionedbecause its memory is retained between eventspymailgui can cache messages in memory--it loads email headers and selected mails only oncefetches only newly arrived message headers on future loadsand has enough information to perform general inbox synchronization checks on deletionspymailgui can simply refresh its memory cache of loaded headers without having to reload from the server moreoverbecause pymailgui runs as single process on the local machineit can leverage tools such as multithreading to allow mail transfers to overlap in time (you can send while load is in progress)and it can more easily support extra functionality such as local mail file saves and opens pymailcgi like all cgi systemspymailcgi consists of scripts that reside and run on server machine and generate html to interact with user' web browser on the client machine it runs only in the context of web browser or other html-aware clientand it handles user requests by running cgi scripts on the web server without manually managed state retention techniques such as server-side database systemthere is no equivalent to the persistent memory of pymailgui--each request handler runs autonomouslywith no memory except that which is explicitly passed along by prior states as hidden form fieldsurl query parametersand so on because of thatpymailcgi currently must reload all email headers whenever it needs to display the selection listnaively reloads messages already fetched earlier in the sessionand cannot perform general inbox synchronization tests this can be improved by more advanced state-retention schemes such as cookies and serverside databasesbut none is as straightforward as the persistent in-process memory of pymailgui the pymailcgi server