Feedback requested: garbage-collecting actions
Stephen Compall
anymore, due to rerendering. The important bits are in docstrings:
parameter *widget-action-symbiosis* (default t):
"Whether to assume that references to actions (e.g. links) are
rendered within the dynamic context of the call to
`render-widget-body' that renders the widget directly containing
said references.
Essentially, when this is NIL, `kill-action-with-render' does
nothing. We strongly recommend doing all rendering for any given
widget within the dynamic context of the `render-widget-body' call
on that particular widget. If this does not describe your code, you
may want to set me to NIL."
function kill-action-with-render:
"When WIDGET is not nil (by default the currently-rendering widget,
aka the innermost `render-widget' call), arrange for ACTION-CODE's
deletion when the browser is no longer rendering it.
We try to be conservative with this, so ACTION-CODE will not be
deleted immediately on the following request, but instead on the
request that follows that, to avoid the race between the browser
rendering cycle and impatient multi-clicking users. Deletion may also
occur when the widget is garbage-collected."
This seems incredibly straightforward given the render-widget-body
methods I write, and the style that we have advocated repeatedly with
regard to separating action handling and rendering on this list, but I
wanted to see if styles in the wild broke these assumptions. Otherwise,
I'll throw trivial-garbage onto the fire (see the end of that last
docstring there) and push it today or tomorrow.
Full patch attached:
Vyacheslav Akhmechet
Leslie P. Polzer
> What happens if I use the back button a few times and click on an action link?
If the page comes from your browser's cache: the action is executed again
because the action id hasn't changed.
If the page is fresh: a new action closure is generated and invoked.
Vyacheslav Akhmechet
<s...@viridian-project.de> wrote:
> If the page comes from your browser's cache: the action is executed again
> because the action id hasn't changed.
action be garbage collected?
Leslie P. Polzer
> Sorry, may be I don't understand what you're doing, but wouldn't this
> action be garbage collected?
No, it's never being deleted from the action hash table as long
as the table exists (i.e. for the duration of the session).
Vyacheslav Akhmechet
<s...@viridian-project.de> wrote:
> No, it's never being deleted from the action hash table as long
> as the table exists (i.e. for the duration of the session).
garbage collected along with the session when it times out.
Stephen Compall
> What happens if I use the back button a few times and click on an
> action link?
If that action link is part of a widget that has since been rerendered,
you'll get an error as if the action didn't exist. If it is a widget
that was just undisplayed, the link would work. Browsers with
Javascript will mostly experience the latter because they can't use Back
to undo an Ajax rerender. None of this applies to clicking Back once,
because we keep actions for a single cycle.
I don't think this is a problem because apps are not in general
guaranteed to work even in minorly untrivial cases with the back button.
Imagine deleting an item of a gridedit, clicking back, and trying to
drill into it. Furthermore, imagine an action linked to a widget that
is no longer part of the tree.
"Leslie P. Polzer" <sky-A/mCt7huS1RhCjiJD...@public.gmane.org> writes:
> No, it's never being deleted from the action hash table as long
> as the table exists (i.e. for the duration of the session).
This deletion is just what this patch does.
--
Sorry but you say Nibiru is a Hoax? Doesnt Exist? So maybe The
Sumerian people doesnt exist also! --Anonymous by way of SkI
Vyacheslav Akhmechet
> If that action link is part of a widget that has since been rerendered,
> you'll get an error as if the action didn't exist.
modified the underlying data, so you can't expect a reasonable result
(although the system should do something graceful). However, most
actions don't modify the data - they only modify the state of UI. Hit
the back button a few times and running into an error is a big deal.
I would disable this feature by default, and have programmers who know
they want this enable it explicitly.
Leslie P. Polzer
On Apr 14, 4:09 pm, Vyacheslav Akhmechet <coffee...@gmail.com> wrote:
> What happens if I use the back button a few times and click on an action link?
original
message and thought you were talking about vanilla Weblocks.
Leslie P. Polzer
> impatient multi-clicking users.
Maybe we should use this opportunity and make sure that actions are
one-shot (i.e. only the first invocation of an action via a certain
action code
has an effect)?
> This seems incredibly straightforward given the render-widget-body
> methods I write, and the style that we have advocated repeatedly with
> regard to separating action handling and rendering on this list, but I
> wanted to see if styles in the wild broke these assumptions.
just result in these actions not being GC'd?
> Otherwise, I'll throw trivial-garbage onto the fire (see the end of that
> last docstring there) and push it today or tomorrow.
a bit florid. From what planet did you snatch it?
Got some tests, too?
Thanks!
Leslie
Vyacheslav Akhmechet
> Maybe we should use this opportunity and make sure that actions are
> one-shot (i.e. only the first invocation of an action via a certain action
> code has an effect)?
interesting what real impact this has on the UI experience.
Personally, I'm a bit wary of the idea, but it would be interesting to
see if it adds any frustration in practice. I would make this an
option that's turned off by default. If it prooves not to cause too
much havoc, you can always change the default. It just seems a bit
dangerous to me...
Stephen Compall
> Maybe we should use this opportunity and make sure that actions are
> one-shot (i.e. only the first invocation of an action via a certain
> action code has an effect)?
I suppose, but I don't think this patch helps with that. It's a
slightly harder problem, because of impatience. Including the
double-clickers.
> I suppose setting up actions outside of widget rendering will
> just result in these actions not being GC'd?
Anyway you shouldn't call render-link and render-form outside of widget
rendering. Calling `make-action' does not do the association, but an
action may only associate with one widget. I think that rendering
actions without one of the `render-*' functions or their macro wrappers
should yield undefined behavior.
I hijacked `log-ui-action', a debugging function that is always called
anyway, for this.
> I reviewed the patch; it looks good although the terminology is
> a bit florid. From what planet did you snatch it?
Trill. Essentially "symbiosis": the action cannot live without its
widget.
> Got some tests, too?
Ha, no. But what it does isn't nailed down yet, I guess.
Vyacheslav Akhmechet <coffeemug-Re5JQE...@public.gmane.org> writes:
> You really don't like the back button, do you? :)
Me too, and I also hate "friendly" URLs. They encourage needless
minimalism in user interface design, which is great for request-response
protocols but crappy for context-sensitive humans. I believe that
they'll have to be mostly abandoned for the UI of web applications in
general to improve. But there's a whole essay there.
> Personally, I'm a bit wary of the idea, but it would be interesting to
> see if it adds any frustration in practice. I would make this an
> option that's turned off by default.
I would rather add a little complexity to make it more acceptable and
have it on by default. There's little sense in an implementation detail
most users have to think about to use, if ever at all.
Leslie P. Polzer
> You really don't like the back button, do you? :)
Weblocks pages (as opposed to static files) should always be served
fresh
from the server and thus feature live action URIs, back button or not.
> Personally, I'm a bit wary of the idea, but it would be interesting to
> see if it adds any frustration in practice. I would make this an
> option that's turned off by default. If it prooves not to cause too
> much havoc, you can always change the default. It just seems a bit
> dangerous to me...
doing multiple widget replacements (less serious but annoying) or
executing backend transactions multiple times (more serious).
Leslie P. Polzer
>
> > Maybe we should use this opportunity and make sure that actions are
> > one-shot (i.e. only the first invocation of an action via a certain
> > action code has an effect)?
>
> I suppose, but I don't think this patch helps with that.
> It's a slightly harder problem, because of impatience. Including the
> double-clickers.
people missing patience. :)
> Anyway you shouldn't call render-link and render-form outside of widget
> rendering. Calling `make-action' does not do the association, but an
> action may only associate with one widget. I think that rendering
> actions without one of the `render-*' functions or their macro wrappers
> should yield undefined behavior.
an error,
throw a warning or do the right thing.
> I hijacked `log-ui-action', a debugging function that is always called
> anyway, for this.
> > I reviewed the patch; it looks good although the terminology is
> > a bit florid. From what planet did you snatch it?
>
> Trill. Essentially "symbiosis": the action cannot live without its
> widget.
> Me too, and I also hate "friendly" URLs. They encourage needless
> minimalism in user interface design,
I'm curious.
> I would rather add a little complexity to make it more acceptable and
> have it on by default.
Leslie
Stephen Compall
> an error, throw a warning or do the right thing.
We can't prevent people from digging into "opaque" structures, or
reimplementing render-link for their own code in a potentially
incompatible or may-be-incompatible-in-future way. We can only say that
doing so isn't supported.
>> I hijacked `log-ui-action', a debugging function that is always called
>> anyway, for this.
>
> For what exactly? I can't associate the 'this' at the end...
The patch.
>> Trill. Essentially "symbiosis": the action cannot live without its
>> widget.
>
> Now I could've thought of that...
Trill, or symbiosis? ;)
>> Me too, and I also hate "friendly" URLs. They encourage needless
>> minimalism in user interface design,
>
> What's the relation between friendly URLs and UI minimalism?
> I'm curious.
Consider the classic-model equivalent of a datagrid with drilldown. In
most cases, the ideal interface is for the search results to remain on
screen, with the appropriate filter and pagination parameters
remembered, while the detailed view appears along with the search
datagrid on the same page.
However, this is not friendly-URL-compatible. The gold standard for a
friendly URL here is to only record the result item type and ID. For
example, a Trac ticket is reached via /ticket/<ticket#>. Recording
search information makes the URL less friendly, because query-strings
are bad for Googleness. So there is a conflict between
user-friendliness and Google-friendliness.
I'm not against people providing selectors that accept friendly or
permanent URLs (e.g. the "Link" link on Google Maps). I'm against the
practices of the Internet forcing web developers to cater to search
engines rather than users.
>> I would rather add a little complexity to make it more acceptable and
>> have it on by default.
>
> +1.
I'm just not sure what that complexity should be. We can't determine
when an action would no longer work, for example. We could keep entries
for more cycles, but `cycle-widget-symbiotic-actions' would grow in time
and space with the cycle count.
Leslie P. Polzer
> We can't prevent people from digging into "opaque" structures, or
> reimplementing render-link for their own code in a potentially
> incompatible or may-be-incompatible-in-future way. We can only say that
> doing so isn't supported.
When we know that an opportunity to mess with opaque structures/protocols
is attractive then we should strive to detect the user messing about in
there.
>>> Trill. Essentially "symbiosis": the action cannot live without its
>>> widget.
>>
>> Now I could've thought of that...
>
> Trill, or symbiosis? ;)
The former one. :)
> However, this is not friendly-URL-compatible. The gold standard for a
> friendly URL here is to only record the result item type and ID. For
> example, a Trac ticket is reached via /ticket/<ticket#>. Recording
> search information makes the URL less friendly, because query-strings
> are bad for Googleness.
Are they? I'm not so sure of that. IME Google will handle query strings
just fine.
> So there is a conflict betweenuser-friendliness and Google-friendliness.
For me friendly in the context of URLs just means that I can bookmark
and copy them easily to others.
> I'm not against people providing selectors that accept friendly or
> permanent URLs (e.g. the "Link" link on Google Maps). I'm against the
> practices of the Internet forcing web developers to cater to search
> engines rather than users.
Considering our different original interpretations we're on the same
page now.
>>> I would rather add a little complexity to make it more acceptable and
>>> have it on by default.
>>
>> +1.
>
> I'm just not sure what that complexity should be. We can't determine
> when an action would no longer work, for example.
Still not sure where it might happen that a dead URL is invoked;
the only case I can think of is having multiple views of a page/widget;
but in this case we're fully desynchronized anyway (that's another
problem domain).
Stephen Compall
> the only case I can think of is having multiple views of a page/widget;
> but in this case we're fully desynchronized anyway (that's another
> problem domain).
Actually, Slava pinpointed the case where you would see a dead URL—in
certain situations when using the Back button, more commonly when
Javascript is disabled. So if we don't care about the back button,
which I argued for earlier in this thread, the patch is fine as-is (+
patch tests trivial-garbage).
Leslie P. Polzer
> Actually, Slava pinpointed the case where you would see a dead URL—in
> certain situations when using the Back button, more commonly when
> Javascript is disabled.
Yes, and I still don't see the point -- action URLs should be fresh
even when the back button is used.
Vyacheslav Akhmechet
<s...@viridian-project.de> wrote:
> Yes, and I still don't see the point -- action URLs should be fresh
> even when the back button is used.
button to work reasonably well (although, fortunately, they don't
expect perfect behavior). If every time they click "back" and then
click on an action they get "action no longer valid" notice, it would
be suicide in terms of the UI design.
I just see it as a pretty big UI annoyance in exchange for very little
benefit. When a session times out, everything can be picked up by the
garbage collector anyway, so what is this for? Very long sessions? I
just don't see what pain the patch solves. Normally this wouldn't
bother me, but I feel like making the back button behavior even worse
is a pretty major issue.
Leslie P. Polzer
>
> On Sat, Apr 18, 2009 at 11:55 AM, Leslie P. Polzer
> <s...@viridian-project.de> wrote:
> > Yes, and I still don't see the point -- action URLs should be fresh
> > even when the back button is used.
> It's just a question of user experience. People expect their back
> button to work reasonably well (although, fortunately, they don't
> expect perfect behavior). If every time they click "back" and then
> click on an action they get "action no longer valid" notice, it would
> be suicide in terms of the UI design.
You're missing my point. One of our basic axioms is that dynamic pages
should come fresh from the server and must not be cached on the client.
And another limitation that we have regardless of whether we have an
action GC or not is that multiple views into the same widget tree (mostly
isomorphous with URL) are not working that well.
So I still don't get how the action GC changes anything here.
Vyacheslav Akhmechet
<s...@viridian-project.de> wrote:
> You're missing my point. One of our basic axioms is that dynamic pages
> should come fresh from the server and must not be cached on the client.
> And another limitation that we have regardless of whether we have an
> action GC or not is that multiple views into the same widget tree (mostly
> isomorphous with URL) are not working that well.
That's true, but in case of back buttons users expect some kind of
support, they're happy with something that doesn't work all the time
but kind of works some of the time. By garbage collecting the actions,
you're breaking that expectation, and I think it's pretty important.
It might be worth doing if you get something significant, but I don't
see any significant benefits.
Leslie P. Polzer
> On Mon, Apr 20, 2009 at 4:13 AM, Leslie P. Polzer<s...@viridian-project.de> wrote:
> > You're missing my point. One of our basic axioms is that dynamic pages
> > should come fresh from the server and must not be cached on the client.
>
> I didn't realize this is a basic axiom. It just isn't how the web works.
where there's no blanket answer -- it's rather that you have to decide
for every part of your web application how long it should be cached
(if it is to be cached at all).
This is true for the most basic CGI script working with data:
If you invoke a stale page that gives you the possibility to delete
object X which no longer exists then you've got the same problem
as we have here.
> That's true, but in case of back buttons users expect some kind of
> support, they're happy with something that doesn't work all the time
> but kind of works some of the time. By garbage collecting the actions,
> you're breaking that expectation, and I think it's pretty important.
> It might be worth doing if you get something significant, but I don't
> see any significant benefits.
default)
because the performance gains are low, but I still don't fully
understand
what it is you're fretting about.
AFAICS you'd need to show me how you'd sensibly use caching for
dynamic parts of an Weblocks app (and why that would be a great
performance gain since I guess that most of the traffic is JS, CSS
and images).
Vyacheslav Akhmechet
history whether we want to or not. We have no control over it. The
only exception is AJAX, but in a real application there will be many
parts where AJAX is turned off for many buttons and links for a
variety of reasons (navigation, etc.) This was the case with my app,
at least.
The users *will* click on the back button and *will* click on old
actions. Currenly, if enough state is still around (which is usually
the case), the actions will do the right thing. If the state isn't
around (which happens occassionally), the actions will do something
semi-reasonable. By semi-reasonable, I mean something that doesn't
freak people out too much.
Actually, I think I understand now what you mean. The fact that AJAX
isn't kept in the history? Then yes, whenever there is AJAX request
for a given URI (other than the first AJAX request for that URI), we
can safely garbage collect the actions of the the previous request
because the page has no chance of being cached in the browser. I was
mostly concerned about non-AJAX requests, which are a big part of most
applications. Does this clear up what I meant?
Leslie P. Polzer
I was talking about actions displayed on pages (which must not
be cached) while you were talking about actions in the URL
that appear when AJAX is turned off (which we of course cannot
prevent from being "cached").
So it's time to talk about your actual problem now.
I think the matter of GCing already used actions is only peripheral
here; instead we should ponder the other problem I mentioned
en passant: how do we treat repeated invocations of the same action?
In my opinion we should just silently ignore the action.
Stephen Compall
> default) because the performance gains are low
Imagine a calendar widget in month or year view, using Weblocks render
instead of Javascript, with an action link for each day, and month/year
setting actions.
Alternatively, imagine that we arrange for Javascript ping to keep
sessions open as long as the browser is open to the webapp. (Recently I
did a search in one webapp, browsed several pages of results, left it
alone in a tab for a couple days, and came back to it.) Hell, the ping
could pick up mysteriously dirty widgets.
Alteralternatively, I may simply be obsessive about these things. This
patch is pretty much a reenactment of
http://groups.google.com/group/gnu.emacs.bug/msg/fe139186a6332e3d
Leslie P. Polzer
> Imagine a calendar widget in month or year view, using Weblocks render
> instead of Javascript, with an action link for each day, and month/year
> setting actions.
Got one of those, but it's not in full production yet so
I can't say anything about the real-world impact.
> Alternatively, imagine that we arrange for Javascript ping to keep
> sessions open as long as the browser is open to the webapp. (Recently I
> did a search in one webapp, browsed several pages of results, left it
> alone in a tab for a couple days, and came back to it.) Hell, the ping
> could pick up mysteriously dirty widgets.
I have such an app too and believe it doesn't really matter much.
But it's not up to full scale yet either so that need not signify
anything.
Anyway, I definitely think that this is useful functionality,
so perhaps we should introduce it right away but turn it off by
default until we agree otherwise.
> Alteralternatively, I may simply be obsessive about these things. This
> patch is pretty much a reenactment of
> http://groups.google.com/group/gnu.emacs.bug/msg/fe139186a6332e3d
Well. I think there are areas of work that would be a better spending
of your time, but we're a volunteer project after all. ;)
Leslie