>>>>>> "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.
I believe my own confusion has led to portraying my confusion quite well. Let's forget what I've stated up until now. I'll do some homework, and try to get a better understanding of the term 'persistence'. fwiw, my understanding of 'persistence', is ``maintaining the consistency and accuracy of data between separate and different processes''. > please > ask about the actual problem and not what you think is the proper > solution. My apologies. I had gotten ahead of myself. > 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, ... in my case, it's not feasible given that I need an object maintained, that is relatively complex in nature. > build links with values in the urls, use > cookies and sessions, etc. I'm not a programmer, particularly not a web programmer, and I really don't want to learn about cookies and sessions... > there are many modules which help with all of > those and more. you are reinventing a very round wheel! :) Many have advised with numerous CPAN-available modules that will do what I want to do. I've been reading up the perldoc on all of them. > persistance is not a function of how it is stored in memory but how you > keep the data alive between seperate processes. Understood. Rephrased: I want to keep data alive in some fashion, *in memory* between 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! :) Io comprendere, chiaramente. > 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! :) Merci beaucoup, Uri. I'll use the info that I've been given to solve my current _issue_, and focus my time on the fundamentals. I'll try to stick with what can't hurt me if I 'leak' on it until I gain more experience... Cheers, and thanks, Steve -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
