(1) Makes sense :). (2) Additional datum: I have this problem with both PostgreSQL (9.3) and SQLite, so it's unlikely to be database specific.
On Saturday, August 29, 2015, Adam Chlipala <[email protected]> wrote: > On 08/29/2015 01:16 AM, Ziv Scully wrote: > >> (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). >> > > This is the easier of the two to respond to. :) > > The behavior you report is expected. The general Ur/Web model is: > (1) The language and implementation help you enforce important invariants, > for security or otherwise. > (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. > > (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. >> > > Hm, I never noticed that before! It may be a concurrency bug in the > runtime system. I'll look into it further. > > _______________________________________________ > Ur mailing list > [email protected] > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur >
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
