DEPRECATED (Cloud Haskell Platform) in favor of distributed-process-extras, distributed-process-async, distributed-process-client-server, distributed-process-registry, distributed-process-supervisor, distributed-process-task and distributed-process-execution
[Imported from JIRA. Reported by Tim Watson [Administrator] @hyperthunk) as DPP-49 on 2013-01-09 10:44:27]
An enabler for issue #31 is the ability to generate an initial RemoteTable from a bunch of dependencies.
Why do we want this?
Consider an application that uses both d-p-platform and d-p-global and another imaginary application d-p-consensus which add support for distributed transactions built on d-p-global's locking. The code in d-p-global will build its own RemoteTable by composing d-p-platform's, and d-p-consensus, if it wants to use d-p-global will compose that RemoteTable with its own definitions. This is simple for the user, because all they need to do is compose the d-p-consensus RemoteTable with their own, however there may be other libraries and/or definitions which are included in the application as dependencies but not part of d-p-consensus.
An example of this might be an application composed of (illustrative imagined applications such as) d-p-monitoring, d-p-pool, d-p-admin and so on. Each time the application developer wants to use a library/component, any __remoteTable definitions for the components will need to be composed. It would be good if we could automate this process to some extent.
What would this look like?
I'm not so sure about this. Perhaps build-time support for building a CH Application that reads the set of inter-dependent components and generates the RemoteTable properly. Perhaps just having some template haskell support that can be invoked by the main application module would do.
[Imported from JIRA. Reported by Tim Watson [Administrator] @hyperthunk) as DPP-49 on 2013-01-09 10:44:27]
An enabler for issue #31 is the ability to generate an initial
RemoteTablefrom a bunch of dependencies.Why do we want this?
Consider an application that uses both d-p-platform and d-p-global and another imaginary application d-p-consensus which add support for distributed transactions built on d-p-global's locking. The code in d-p-global will build its own
RemoteTableby composing d-p-platform's, and d-p-consensus, if it wants to use d-p-global will compose thatRemoteTablewith its own definitions. This is simple for the user, because all they need to do is compose the d-p-consensusRemoteTablewith their own, however there may be other libraries and/or definitions which are included in the application as dependencies but not part of d-p-consensus.An example of this might be an application composed of (illustrative imagined applications such as) d-p-monitoring, d-p-pool, d-p-admin and so on. Each time the application developer wants to use a library/component, any
__remoteTabledefinitions for the components will need to be composed. It would be good if we could automate this process to some extent.What would this look like?
I'm not so sure about this. Perhaps build-time support for building a CH Application that reads the set of inter-dependent components and generates the
RemoteTableproperly. Perhaps just having some template haskell support that can be invoked by the main application module would do.