>>>>> "SB" == Steve Bertrand <st...@ibctech.ca> writes:
SB> The idea started off as a way to store data in memory for a very short SB> period of time between invocations of a CGI application. I then got SB> thinking about how to do the same thing, without CGI. then i was right about the XY problem. you are seeking some persistant store in CGI and yet you decided to ask about some obscure and likely impossible solution involving keeping ram addresses the same during disk storage and retrieval. that is what bothered me and the others. please ask about the actual problem and not what you think is the proper solution. we can solve it better and faster if we tackle the real problem and not some wild goose chase you are already upon. SB> For instance, I have a Perl program that generates a hash of SB> numbers. This program needs to exit completely before another SB> program loads about a second later, and retrieves the data. In SB> this case, the first program has no way of passing the hash to the SB> second as a parameter. there are many ways to handle persistance between cgi calls. you can use hidden variables in forms, build links with values in the urls, use cookies and sessions, etc. there are many modules which help with all of those and more. you are reinventing a very round wheel! :) SB> I was naive enough to think perhaps I could do something like this: SB> my %hash = ( this => 'that', these => 'those' ); SB> my $hash_ref = \%hash; SB> # put the ref's string data in another scalar SB> my $manual_ref = "HASH(0x8100af0)"; why would circular structures mean they can be stored any better than other structures? GC has nothing to do with persistance. SB> I knew that there were ways to temporarily store the data to disk and SB> then re-fetch it, but not that the data could avoid the disk while still SB> being persistent. Thanks to those for the suggestions. persistance is not a function of how it is stored in memory but how you keep the data alive between seperate processes. http and cgi's biggest failing is its request/response protocol without a persistant connection so you have to build persistance on top of a temporary connection. all those solutions i mentioned above are ways around this issue. SB> All in all, when I get an idea, I generally like to take the path of SB> resistance, so I can learn for myself why something does/doesn't work. SB> For the most part, I don't like to re-invent the wheel, unless SB> re-inventing the wheel will teach me something important (such as being SB> told not to do it :) or give me better understanding as to why not to do SB> it, instead of just being told not to. don't reinvent this wheel! it requires a deeper understanding of persistance than you have at the moment. it is not a path of learning but of deep pain! :) SB> It's kind of like the time I was a kid, and I was told not to touch the SB> cow fence. By touching it, I quickly learnt by my own experience that if SB> I take a leak at the side of a road, ensure there isn't a steel fence SB> nearby... don't piss on this problem! :) uri -- Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
