[Ur] Busy indicator

[Adam Chlipala]

I'm not convinced yet.  I try to follow the standard credo of 
(academic?) PL designers: implement a minimal core with code extension 
hooks and let programmers add what they need.  No one has ever asked for 
this feature before, and it's not clear that it's nearly fundamental.

On 08/28/2016 08:50 PM, Saulo Araujo wrote:
> If I may, I'd like to advocate for a solution closer to the one that I 
> have prototyped. I still believe the rpcCount source should be part of 
> the standard library and that the rpc function should update the 
> rpcCount source. Suppose, for example, that I am using a module that 
> someone other than me developed and this module invokes the function 
> rpc. If the rpc function updates the rpcCount source, my application 
> would be able to show the busy indicator, which would not be true in 
> this other solution.

But there's another story that shows why it's an /advantage/ not to be 
able to detect the RPCs in other modules: encapsulation. Library authors 
want to be able to write code that hides details of exactly what is 
going on.  When you upgrade a library, you may find different RPC-count 
behavior, which would be like being able to detect that a dictionary 
class had gone from using hash tables to using binary search trees.

I think this really is a serious usability issue.  In your original 
example, what happens when your program is using a library that, between 
versions, starts making more RPCs, so your UI says that "your" code is 
"still working" when actually it's an expensive RPC in a library?

To me, it makes more sense to have a library defining a concept of RPC 
groups, with special calls to make RPCs given groups as parameters.  
Isn't it also nice to be able to measure separate categories of RPCs 
separately?

To add such behavior on top of existing Ur/Web code, you just need to 
redefine the identifier [rpc] at the top of a file, which could be 
accomplished by [open]ing a library module.

> In any case, this other solution made me think that maybe what we need 
> in Ur/Web is something like the HTTP interceptors of AngularJS (look 
> for interceptors in https://docs.angularjs.org/api/ng/service/$http). 
> In general terms, AngularJS allows one to register one or more 
> listeners/observers that it calls whenever it is about to make a HTTP 
> request and when it receives a HTTP response. This design is very 
> general, allowing any kind of behavior related to HTTP requests to be 
> plugged in, even in code developed by a third party. However, I am not 
> sure if/how this fits in the pure world of Ur/Web.

I have essentially the same worries about this idea: (1) as no one has 
asked for it before, I'm not convinced that it's fundamental enough to 
belong in the core; (2) it's hard to do without breaking encapsulation, 
which I care about more than "convenience" in adding nonstandard 
semantics to standard operations (which is /less/ convenient for all the 
folks out there reasoning about their code and what it used to do vs. 
what it does now!).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20160901/b832b417/attachment.html>