search

haskell-distributed / distributed-process-platform

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
http://haskell-distributed.github.com
BSD 3-Clause "New" or "Revised" License
47 stars 17 forks source link

Configuration APIs #46

Open hyperthunk opened 11 years ago

hyperthunk commented 11 years ago

Following on from issues #30 and #31 (though many more features may depend on it), it is fairly commit to need static configuration in a distributed system. It'd be nice to have a standard API for managing this, though I suspect there will be as many opinions about which format is best as there are developers using the tools.

ericbmerritt commented 11 years ago

I think its more about providing the person assembling the Release (at least in Erlang) with a single stable means to configure all the applications in that release. If each application (in the OTP sense) has some different configuration semantic it would be a nightmare for the Release Assembler.

hyperthunk commented 11 years ago

Yes indeed. I think your comments in issue #31 about making the compiler check all the configuration is probably the right thing to do here. We should aim to provide some standardisation for components and sub-systems, but probably that'll just come out in the wash as the application (or whatever) concept grows.

ericbmerritt commented 11 years ago

In general, for the high level release configuration I don't think you are going to be able to compile that. That could very well be something that is going to need to change for every host that the 'release' is running on.

Thats very different then application/release metadata which is, for all intents and purposes, static.

Just something to keep in mind.