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
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
