Re: [SM-DEVEL] $compose_messages not saved in session after being unset? (1.5.x)

[Paul L. <pa...@sq...>]

On 7/8/07, Paul Lesniewski <pa...@sq...> wrote:
> On 7/7/07, Jonathan Angliss <jo...@sq...> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Michael Andreas wrote:
> > >
> > > Robert L Mathews wrote:
> > >> Even with the above patch, you can still make the hidden "restoremessages"
> > >> field get huge by starting to reply to many messages but not sending them
> > >> or saving them as a draft, so the general issue is still potentially a
> > >> problem.
> > >>
> > >
> > > Sorry to bump an old thread, but I think this is a real issue. With a fresh
> > > session, compose.php loads at ~9 KB. Just click compose over and over again,
> > > and you'll see the size increasing ~2 KB at every new request. The hidden
> > > "restoremessages" field would get more bulked with every
> > > composed-but-not-sent action. We're talking a possible ~200 KB (or even
> > > more) for a compose screen here, which I think is a huge number for
> > > low-bandwidth users. I don't know, it just doesn't feel right (or good
> > > practice) to put such data in an input element (though I got no better
> > > alternatives than the current method, sorry).
> >
> > Wow... you made me dig for the original one :)  Looking at stable, it's
> > not been fixed there, nor has it been fixed in devel either.
> >
> > What's weird about this feature is that we make each compose message
> > unique by assigning it a new ID, but give the user no method of getting
> > back to an old compose in the event they may have accidentally hit close
> > (yes I know of the auto save plugin).
>
> That is, "quicksave".  Quicksave saves message text in real time (in a
> cookie, which naturally has size limitations, and in the future via an
> AJAX interface, which won't have size limitations), which is different
> than a message that is actually submitted to the server and stored in
> session.  However, it might be useful to try to make use of that
> information.  Dunno if Quicksave can, but maybe I'll try to have a
> look.

After looking at this a bit, I'm not sure I see the use of
$compose_messages at all.  Supposedly it is placed in the form as a
hidden input so after a session timeout on the compose page, the whole
thing can be restored, BUT what does SM ever do with them anyway?

Did someone a long time ago think some day we'd have a screen where
the user could look at a list of "lost" messages that were for some
reason never sent?  Otherwise, I can't think of anywhere this
information would be used.  A grep shows the data isn't used anywhere
for that sort of thing -- compose.php looks like it can accept a
$composesession input to recall one of them, but I don't see anywhere
that we use it...?

Unless I am missing something (please correct me), I think it should
be removed.  This would help clean out $_SESSION as well as keep the
compose page more lightweight.

The usefulness of recovering any messages stored in the $_SESSION is
very low because the user has to click submit to get the message into
the session, and usually the message is lost because the Send button
is never pressed.  In the more rare case that Send is clicked but the
message is not sent, the compose screen reloads with the message
again, so it is not lost anyway.  Sure, the user could then click away
(e.g., back to the INBOX) without sending, so that message is saved in
session, but there is not any way to restart that message in SM, and
I'm not sure it adds much value to create a mechanism to retrieve it,
especially when the Quicksave plugin is probably good enough for that.

In the case of a session timeout on the compose screen, the only data
you really need to restore is the message that was being composed (not
older ones), and that data will be in the standard message POST
fields, so we don't need any hidden compose_messages data at all.

Thoughts?  I think we should clear out this code, at least in 1.5.2.

 - Paul