> If something is more comprehensive, people tend to think of it > as less flexible, and I aggree (most of the time). But this > shouldn't be the case with CGI::Session at all. It offers > the same flexibility (and even more) that Apache::Session does. > > And reading and writing HTTP cookies is the feature of CGI::Session > one can make use of to condense the Perl code even more :-). You > still have to deal with such issues in CGI applications, so why > not have such utilities in the library itself ;-) You make two points here. The first is that CGI::Session is as flexible as Apache::Session. As I mentioned, I'm only operating off of a brief browse of the docs, so that may be perfectly correct. Can I load use it in a command-line script without running into module dependacies that I wouldn't with A::S? Can I use it for tasks OTHER than a CGI::Session? If so, then you may be correct. If not, I'll stand by my earlier assumption. Your second point is why not do it in CGI::Session. I have no disagreement, except that sometimes you want to control those items yourself, (as in the case of a command line tool) those items are not involved. I've run into both of those situations. I am not saying that CGI::Session is bad at all. I'm saying that, based on a browse of the docs, it attempts to meet different needs than Apache::Session, and so a user should select the tool that best meets the needs of their situation. (Anyone on the CGI::App list interested in any continuation of this topic should let me know -- since we're not talking CGI::App anymore, any of my future replies will be off-list) -- SwiftOne suppressed --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/suppressed/ To unsubscribe, e-mail: suppressed For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.