[Ur] Busy indicator

[Saulo Araujo]

Hi Adam,

Thanks a lot for your comprehensive answer.


> 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?
>
>
In this particular case, the UI would correctly show to the user that there
is some ongoing work.


> 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?
>
>
It surely is.


> 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.
>
>

Rather than changing every file that is part of a library (possibly
developed by others, in which case I may not even have its source code), I
would prefer redefining the functions requestUri and xhrFinished to update
the rpcCount source. Both options seem like a hack to me. However, the
latter is a more centralized one.

> 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>
> 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;
>

Fair enough.


> (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!).
>

>
I think that AngularJS (and others) provides a "poor's man" aspect oriented
programming. Looks like there has been some success in combining
aspect-oriented and functional programming (
http://repository.upenn.edu/cgi/viewcontent.cgi?article=1404&context=cis_papers)
in a less ad hoc way, but it surely seems a lot of work.

Again, I would like to thank you very much for your comprehensive answer.

Sincerely,
Saulo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20160902/f8c05507/attachment.html>