I don't have time to weigh in on this proposal right now, but I have several comments...
On 24 Jan 2014, at 17:19, Facundo Domínguez wrote: > Rationale > ======= > > We want the language extension to meet the following requirements: > > 1. It must be a practical alternative to the remoteTable functions > in the distributed-static package. > Agreed - this is vital! > 2. It must not change the build scheme used for Haskell programs. A > collection of .o files produced from Haskell source code should still > be possible to link with the system linking tools. > Also vital. > 3. It must not restrict all communicating processes using the > extension to be launched from the same binary. > I personally think this is very valuable. > About the need for using different binaries > ============================== > > While using distributed-process we found some use cases for supporting > communicating closures between multiple binaries. > > One of these use cases involved a distributed application and a > monitoring tool. The monitoring tool would need to link in some > graphics libraries to display information on the screen, none of which > were required by the monitored application. Conversely, the monitored > application would link in some modules that the monitoring application > didn’t need. Crucially, both applications are fairly loosely coupled, > even if they both need to exchange static values about bindings in > some modules they shared. Indeed - this is an almost canonical use-case, as are administrative (e.g., remote management) tools. > As the application depends on shared libraries, now a tool to collect > these libraries would be required so they can be distributed together > with the executable binary when deploying a Cloud Haskell application > in a cluster. We won’t delve further into this problem. Great idea. > > Another possible line of work is extending this approach so a process > can pull shared objects from a remote peer, when this remote peer > sends a static value that is defined in a shared object not available > to the process. This would go a long way towards answering our questions about 'hot code upgrade' and be useful in many other areas too. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
