(1) Makes sense :).<div><br></div><div>(2) Additional datum: I have this problem with both PostgreSQL (9.3) and SQLite, so it's unlikely to be database specific.<span></span></div><div><br><br>On Saturday, August 29, 2015, Adam Chlipala <<a href="mailto:adamc@csail.mit.edu">adamc@csail.mit.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/29/2015 01:16 AM, Ziv Scully wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(1) Say that [handler : unit -> transaction page] makes a write to a database. Normally we can't just use [handler] as a link without a [safeGet] in the relevant .urp file. However without exposing [handler] in the .urs file or adding the [safeGet], we can do [<form><submit={handler}></form>]. This makes [handler] accessible by simply typing in a URL, even if it has destructive effects, because the form handler expects no fields. There's a simple workaround for now: add a [<hidden{#Dummy}/>] to the form (and change the type of [handler] accordingly).<br>
</blockquote>
<br>
This is the easier of the two to respond to. :)<br>
<br>
The behavior you report is expected.  The general Ur/Web model is:<br>
(1) The language and implementation help you enforce important invariants, for security or otherwise.<br>
(2) However, the model is still that any page handler could be called with any arguments (and any applicable HTTP verb!) at any time.  The "side effects must use PUT" rule is only enforced for user interaction sequences that follow the normal control flow of your application, with no "protection" against wise guys who craft their own URLs.  IMO, you should make sure that a user calling a URL "out of order" may be able to break his own state, in a relatively benign way, but not break anyone else's state.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(2) Sometimes doing "many" (order of 6) channel operations slows down the server considerably, causing all requests to stall for a bit. The stall isn't permanent, but often after the stall resolves, some small subset of the messages don't make it to their recipients. The clients who missed messages might still receive future messages but will never receive the ones they missed. I found that something similar occurs with the official Chat demo (try joining the same channel in ~8 tabs in quick succession), so I don't think the issue is specific to my app. Has anyone run into this before? I messed with the .urp file a little bit but nothing helped.<br>
</blockquote>
<br>
Hm, I never noticed that before!  It may be a concurrency bug in the runtime system.  I'll look into it further.<br>
<br>
_______________________________________________<br>
Ur mailing list<br>
<a>Ur@impredicative.com</a><br>
<a href="http://www.impredicative.com/cgi-bin/mailman/listinfo/ur" target="_blank">http://www.impredicative.com/cgi-bin/mailman/listinfo/ur</a><br>
</blockquote></div>