| [reply] |
Learn by reinventing the wheel (altho this is probably gonna get me some downvotes...)
The reason why I'm reinventing the wheel all the time (like doing Session stuff), is so I learn. Complex things are really a whole lot of simple things combined into a big, complex thing :) So if you really want to learn, you could just grab a good tutorial, learn the basics, come up with a session routine of your own, (ab)use it, drop it like a brick and go for a ready-to-use module from CPAN :) (OR come up with the routine, tweak it ALOT and relase it to CPAN)
Note: There are things you just shouldn't reinvent, CGI.pm is one of them.
Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur. | [reply] |
I upveoted you because I agree that a good way to learn is to tinker with stuff. However, you certainly shouldn't clutter CPAN with duplicate modules. Perhaps the best thing to do is start with the appropriate CPAN module and make it do what you want then release the changes back to the author so that they can be incorporated into the next version. Hopefully that way you learn the guts & theory, think of some stuff that you never realized about the problem before and everyone benefits since another set of eyeballs have looked at the code and another brain has thought about it. The end result should be a more powerful, more general, more reliable piece of software.
BTW session management is tricky. The Apache::Session modules is very cool because it has different pluggable lock and storage modules. Getting storage correct is non-trivial since you need to decide what semantics your sessions should have. Things to think about are how you want your session to behave when two requests happen simutaneously. Will the change that happens second blow away the first even if the first has not yet written the state? Will the second page block until the first change happens? If you decide that you do not need blocking did you remember at least to lock the session object when it is being read and written so that changes mid-read or write do not corrupt the session.
You can choose not to think about this and your code will work most of the time, but when the load gets high and pages start holding the sessions open for a while you will start getting weird errors that are very hard to track down. The Apache::Session code has a Transaction argument you can pass to lock the session from when it is read from disk until it is closed. It also locks the object when it is being changed (even if you are not in transactional mode).
-ben
| [reply] |