|
Directory structure for a release: msg#00390lang.erlang.general
I am trying to package up some code according to OTP principles so that I can do code upgrade / downgrade and have bootable nodes and a pool of clients. I am probably getting confused between traditional code partitioning and the OTP way so I wanted a little guidance. I am trying to avoid having a lump of code that ends up causing things like in the OTP distribution where some useful utilities are part of the HTTP module and so on. Since I am just starting now is the time to get the directory partitioning right. I have the following "code sets": 1) Utilities (bin_utils, tcp_proxy) 2) HTTP utilities (web_utils, ProxyModule) 3) Host supervisor I've got all the lib/App/ebin, src, priv and so on, but my question has to do with what is an app and what is a code organization structure. I expect to use #1 Utilities for many projects. I expect to use #2 HTTP Utilities only for this application. Likewise the hostsupervisor is specific to this application. Originally, I thought to put all three in separate directories and to have other directories for other shareable or non- shareable pieces, but it means each becomes an app with *.app file and so on. It also means (I believe) that they are regarded as part of an application tree whether or not they have processes running or are code-only. Now I am wondering if one of the two following approaches is better: 1) All in one directory 2) Host supervisor / HTTP utils in one; Utilities in other Reasons for #1: a) They are all part of a single application b) Code upgrades can still occur on a module basis Reasons for #2: a) The first directory is really the application b) Utilities is shareable to other applications One of my concerns is whether code is compiled and/or loaded if it is not used. In other words, if I use the first approach and dump everything in a single app directory and later write a new app that uses some utilities, will it require all the modules in the app directory or only the ones listed in the script file. What advantages and disadvantages are there to having an app directory that contains only code and no processes as in #2? Does it make configuration harder with no gain in code partitioning or loaded binaries? If I write a 2nd application do I just dump it in the same directory and write a different release configuration, or should I go with approach #2 so that I create a new app directory? Is it best to have as few directories as possible under lib, but at least one per bootable application? Is there any advantage to partitioning the directories on a finer scale so that they are equivalent to libraries of related modules, or should there be one big utilities library (code-only app) containing all shareable code (a la stdlib)? jay |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: upgrade of supervisors child specifications: 00390, Martin Bjorklund |
|---|---|
| Next by Date: | Re: Directory structure for a release: 00390, Wiger Ulf |
| Previous by Thread: | upgrade of supervisors child specificationsi: 00390, Bengt Kleberg |
| Next by Thread: | Re: Directory structure for a release: 00390, Wiger Ulf |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |