Menu
▾
▴
Re: [PHPiCalendar-DEV] Session support
|
From: Jared <xe...@si...> - 2002-10-04 17:19:21
|
I just thought of something else. Right now, the processed calendar would only have a range of 3 months. This month, last month, and next month. If someone is looking at last month, they don't need to know next month but rather, two months before that. So it would be very common for two people to not be looking at the same set of required data as the next. This could be extended out further, if needed, to any range of time. I don't know what is acceptable or if sessions truly are the best way to go. -Jared On Friday, October 4, 2002, at 12:08 PM, Jared wrote: > Hmm, interesting idea. I like it better than sessions. The only reason > we want sessions right now is to store the processed cals. If the > calendar is already processed, the next users can use that as well. I > like it. > > Chad? > > -Jared > > BTW, my AIM just went down for some odd reason, so I'm not online. > > On Friday, October 4, 2002, at 12:05 PM, Matt Jarjoura wrote: > >> On 10/4/02 12:54 PM, "Jared" <xe...@si...> wrote: >> >>> On Friday, October 4, 2002, at 11:44 AM, Chad wrote: >>> >>>> Ok, so I want to talk about Sessions.... how are we going to speed >>>> up >>>> and lighten processor load for 0.6 PHP iCalendar? :-) >>> >>> Well, I think if we write all the main variables to a session along >>> with the filemtime() of the last parsed file, it can check each page >>> load whether the file is different and if not, use the session data. >>> If >>> it is different, parse the file again and write it to the session. I >>> don't think it's too complicated, really. We just need $master_array, >>> $getdate, $cal, and $cal_modDate. I don't know if we need anything >>> else >>> (at least, I can't think of it off the top of my head). >>> >>> -Jared >>> >> >> >> In that case, I would store all the variables inside on array and run >> the >> "serialize()" function and save the serialized data to a file with >> the same >> file date and time as the original ical file. Then it would be easy >> to >> check the date of the "compiled" code to the ical file. If the same, >> just >> "unseralize()" the array back into php, and no processing is >> required. This >> way if you have 10 new users in a second, it won't kill the CPU. Cuz >> a new >> session will be created per user per browser. 10 new users with a >> session >> will process the original ical file 10 times. ;-) >> >> ========================== >> Matt Jarjoura >> ========================== >> | UMBC | Phi-Delta 313 | >> ========================== >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
