Time for the new guy to respond!
Nathan Ehresman wrote:
> I'm don't really see it that way.
> I don't think there really is much overhead involved. You need to be
> sure you call session_start() for each page, and include an extra
> parameter in the URL. We could even have the session id stored in a
You're right. There isn't much overhead at all. I use session stuff all
the time, and hardly ever notice any difference in my application with or
without it. Also, if the user has cookies eneabled on their browser, which
they need to already anyway, you don't even need to pass the sess_id in the
URL. It is all done internally with PHP's session management system
> cookie so we don't even need to bother with sticking it in the URLs.
> You don't even need to bother reconfiguring and compiling PHP itself
> (although you should change php.ini for your needs).
> In fact, I think that without sessions it could get really messy. This
> isn't done yet, but think about what would need to be done if while
> reading a message, a user clicks on the "Next Message" or "Next Unread
> Message" link. You need to get all the headers for the mailbox again,
> sort them, find the position of the current message in that list, then
> find the next unread message. If this sorted data is cached in on the
> server, you only need to find the next message.
right. at a bear minimum, you can store current place in the messages.
You can load and cache all of the users preferences once, so you don't need
to keep opening their pref file. Possibly you could store the whole
message header stream in the session too. I don't know how this would
effect preformace when you find someone who has a couple thousand messages
in thier inbox (like my boss) but I suppose that's what testing is all
> Using it as a cache type mechanism would greatly speed up navigation
> inside of a mailbox.
> Another use for it could be for the plain 'ol HTML address book. The
> same link that is currently used to load up the search window could take
> you to a page that lets you search, but it stores anything already
> written on the compose screen. That way if they write their email and
> then select who it goes to, they don't lose the body of their message,
> and we don't need to pass the message body in the URL (ha ha!!).
Uhhh, that would be a good thing!
> To summarize my feelings on this:
> - it isn't much overhead (especially if cookies are used to save the
> session id)
> - using sessions could really be handy
That's an understatement!