<div dir="ltr"><div><div>Hi Adam,</div><div><br></div><div>Thanks a lot for your comprehensive answer.</div><div><br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><br>
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?<br>
<br></div></blockquote><div><br></div><div><div><div>In this particular case, the UI would correctly show to the user that there is some ongoing work.</div><div> <br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
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?<br>
<br>
</div></blockquote><div><br></div><div><div>It surely is.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">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.<span class="gmail-"><br>
<br></span></div></blockquote><div><br></div><div><div><br class="gmail-Apple-interchange-newline">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.</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>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 <a href="https://docs.angularjs.org/api/ng/service/$http" target="_blank"></a><a href="https://docs.angularjs.org/api/ng/service/$http" target="_blank">https://docs.angularjs.org/<wbr>api/ng/service/$http</a>).
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.</div>
</div>
</div>
</blockquote>
<br></span>
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; </div></blockquote><div><br></div><div><div>Fair enough.</div><div> <br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">(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 <i>less</i>
convenient for all the folks out there reasoning about their code
and what it used to do vs. what it does now!).<br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div><br></div><div class="gmail_extra"><div><div>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 (<a href="http://repository.upenn.edu/cgi/viewcontent.cgi?article=1404&context=cis_papers">http://repository.upenn.edu/cgi/viewcontent.cgi?article=1404&context=cis_papers</a>) in a less ad hoc way, but it surely seems a lot of work.</div><div><br></div><div>Again, I would like to thank you very much for your comprehensive answer.</div><div><br></div><div>Sincerely,</div><div>Saulo</div></div></div></div>