어떤 시점에서 구성 파일이 프로그래밍 언어가됩니까?

어떤 시점에서 구성 파일이 프로그래밍 언어가됩니까?

---

나는 한동안 구성 파일과 코드와의 관계에 대해 고민해 왔으며 바람의 날과 방향에 따라 내 의견이 바뀌는 것 같습니다. Lisp를 배우면서 처음 얻은 깨달음으로 계속 돌아 오지만, 데이터와 코드 사이에는 거의 차이가 없습니다. 이것은 구성 파일의 경우 두 배로 사실입니다. 올바른 관점에서 보면 Perl 스크립트는 perl의 구성 파일에 불과합니다. 이는 QA 및 구성 파일 변경을 담당해야하는 분과 같은 작업에 상당히 무거운 결과를 초래하는 경향이 있습니다.

설정 파일에서 본격적인 언어로의 이동은 일반적으로 느리고 일반적인 시스템을 갖고 자하는 욕구에 의해 주도되는 것 같습니다. 대부분의 프로젝트는 로그를 작성할 위치, 데이터를 찾을 위치, 사용자 이름 및 비밀번호 등과 같은 몇 가지 구성 항목으로 작게 시작하는 것 같습니다.하지만 그 후 성장하기 시작합니다. 기능을 켜거나 끌 수 있습니다. 작업의 타이밍과 순서가 제어되기 시작하고 필연적으로 누군가 로직을 추가하기를 원합니다 (예 : 머신이 X이면 10을 사용하고 머신이 Y이면 15를 사용). 특정 시점에서 구성 파일은 도메인 특정 언어가되고 그 언어는 잘못 작성됩니다.

이제 무대를 설정하기 위해 뛰어 들었으므로 여기에 내 질문이 있습니다.

1. 구성 파일의 진정한 목적은 무엇입니까?
2. 구성 파일을 단순하게 유지해야합니까?
3. 개발자, 사용자, 관리자 등의 변경을 책임 져야하는 사람은 누구입니까?
4. 소스를 제어해야합니까 (질문 3 참조)?

앞서 말했듯이이 질문에 대한 제 답변은 계속 바뀌지 만 지금은 다음과 같이 생각하고 있습니다.

1. 프로그래머가 아닌 사람이 대량의 동작을 빠르게 변경할 수 있도록
2. 예, 거칠지 않은 것은 코드에 있어야합니다.
3. 사용자는 구성 파일을 담당해야하며 프로그래머는 구성 파일과 응용 프로그램을보다 세밀하게 제어 할 수있는 코드 사이의 구성 계층을 담당해야합니다.
4. 아니요,하지만 더 미세한 중간 레이어는

---

매우 흥미로운 질문입니다!

저는 설정 파일이 매우 빠르게 본격적인 프로그램이 될 수 있다는 사실에 전적으로 동의하기 때문에 설정 파일을 매우 간단한 "key = value"형식으로 제한하는 경향이 있습니다. 예를 들어, OpenSER를 "구성"하려고 시도한 사람은 누구나 구성이 아니라 (고통스러운) 프로그래밍이라는 느낌을 알고 있습니다.

오늘날 상상할 수없는 방식으로 애플리케이션을 매우 "구성 가능"해야 할 때 정말 필요한 것은 플러그인 시스템 입니다. 다른 사람이 새 플러그인을 코딩하고 나중에 애플리케이션에 연결할 수있는 방식으로 애플리케이션을 개발해야합니다.

따라서 귀하의 질문에 답하려면 :

1. 구성 파일의 진정한 목적은 무엇입니까?

   애플리케이션을 설치할 사람들이 호스트 이름, 스레드 수, 필요한 플러그인 이름, 해당 플러그인에 대한 배포 매개 변수와 같은 배포 관련 매개 변수를 사용할 수 있도록 허용하려면 이 원칙의 예에 대한 FreeRadius의 구성) 등. 확실히 비즈니스 로직을 표현할 장소가 아닙니다.

2. 구성 파일을 단순하게 유지해야합니까?

   명확히. 당신이 제안했듯이, 설정 파일의 "프로그래밍"은 끔찍합니다. 나는 그것을 피해야한다고 믿는다.

3. 개발자, 사용자, 관리자 등의 변경을 책임 져야하는 사람은 누구입니까?

   일반적으로 애플리케이션을 배포하는 관리자를 말합니다.

4. 소스를 제어해야합니까 (질문 3 참조)?

   저는 일반적으로 구성 파일 자체를 소스 제어 하지 않지만 모든 매개 변수와 기본값, 작업을 설명하는 주석을 사용하여 템플릿 구성 파일을 소스 제어합니다. 예를 들어 구성 파일의 이름이 database.conf이면 일반적으로 라는 파일을 소스 제어합니다 database.conf.template. 물론 저는 개발자로서 제가하는 일에 대해 이야기하고 있습니다. 관리자로서 각 설치에 대해 선택한 실제 설정을 소스 제어하고 싶을 수 있습니다. 예를 들어, 수백 대의 서버를 원격으로 관리하고 해당 구성을 추적해야합니다. 소스 제어를 사용하여이를 수행하기로 선택했습니다.

---

편집하다: 위의 내용이 대부분의 응용 프로그램에 해당한다고 생각하지만, 물론 예외는 항상 있습니다. 예를 들어 애플리케이션은 사용자가 복잡한 규칙을 동적으로 구성하도록 허용 할 수 있습니다. 대부분의 이메일 클라이언트는 사용자가 이메일 관리에 대한 규칙을 정의 할 수 있도록합니다 (예 : " 'john doe'가 보낸 모든 이메일은 To : 필드에 포함되지 않은 이메일은 삭제되어야합니다."). 또 다른 예는 사용자가 새롭고 복잡한 상업용 제안을 정의 할 수있는 애플리케이션입니다. 또한 사용자가 복잡한 데이터베이스 보고서를 작성할 수있는 Cognos와 같은 애플리케이션에 대해 생각할 수도 있습니다. 이메일 클라이언트는 사용자에게 규칙을 정의 할 수있는 간단한 인터페이스를 제공 할 것이며 이것은 복잡한 구성 파일 (또는 약간의 코드)을 생성합니다. 반면에 상업 오퍼에 대한 사용자 정의 구성은 구조화 된 방식으로 데이터베이스에 저장 될 수 있습니다 (단순한 키 = 값 구조도 코드 일부도 아님). 그리고 일부 다른 응용 프로그램은 사용자가 파이썬이나 VB 또는 다른 자동화 가능 언어로 코딩 할 수도 있습니다. 즉 ... 마일리지가 다를 수 있습니다.

---

확인. 정말 간단한 구성을 원하는 사용자가있을 것입니다. 사용자에게 제공해야합니다. 동시에 "이것을 추가 할 수 있습니까? 구성 파일에서 어떻게합니까?"라는 요청이 계속 발생합니다. 두 그룹을 모두 지원할 수없는 이유를 알 수 없습니다.

현재 작업중인 프로젝트는 구성 파일에 Lua를 사용합니다. Lua는 스크립팅 언어이며이 시나리오에서 매우 잘 작동합니다. 기본 구성 의 예를 사용할 수 있습니다 .

주로 key = value 문이며, 여기서 value는 Lua의 기본 제공 유형 중 하나 일 수 있습니다. 가장 복잡한 것은 목록이며, 실제로는 복잡하지 않습니다 (단지 구문 문제입니다).

이제 나는 누군가 시작할 때마다 서버의 포트를 임의의 값으로 설정하는 방법을 묻는 사람을 기다리고 있습니다.

---

Recently I was working upon a project and I realised that I wanted to have conditionals inside my configuration file - which had previously just been a pretty simple one of the form:

key = val
key2 = val
name = `hostname`

I didn't want to write a mini-language, because unless I did it very carefully I couldn't allow the flexibility that would be useful.

Instead I decided that I'd have two forms:

1. If the file started with "#!" and was executable I'd parse the result of running it.

2. Otherwise I'd read it as-is

This means that I can now allow people to write "configuration files" that look like this:

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

This way I get the power of a dynamic configuration file if the user wants to use it, and the simplicity of not having to write my own mini-language.

---

Every (sufficiently-long-lived) config file schema eventually becomes a programming language. Due to all the implications you describe, it is wise for the config-file designer to realize she is authoring a programming language and plan accordingly, lest she burden future users with bad legacy.

---

I have a different philosophy about config files. Data about how an application should be run is still data, and therefore belongs in a data store, not in code (a config file IMO is code). If end users need to be able to change the data, then the application should provide an interface to do so.

I only use config files to point at data stores.

---

You could turn to theory of computation to define what counts as a programming language. If your configuration file format is Turing Complete then it reasonably counts as a programming language. By this definition, a file format to describe levels of Sokoban counts as a programming language (see here). There are other levels of complexity below Turing Complete that may also count, such as Regular Grammars and Pushdown Automata.

Another way to look at it is that many config files are only capable of data markup, whereas a proper programming language must be able to implement algorithms. For example, JSON is a config file format, whereas ECMA Script is a programming language.

---

Here's my thoughts:

1. To allow the runtime behavior of an application to be modified easily. This can be by programmers or non programmers, depending on the needs. This can be during development, but I often view configuration files as a way to help make a program more flexible at any point.

2. Yes. I think config files should be as simple as possible, given the constraint that you may need various options to control different behaviors of your runtime. I prefer grouping configuration settings, and simplifying them as much as possible.

3. Depends on what and why the change is being made. If users are going to be changing it, a front-end should be made to hide them from the details. The same is often true of non-developers in general.

4. I often source control the "default" configuration, but have a way to override this per system for the actual runtime.

As for adding logic to the config file - I'd avoid this. I think it's better to just have the configuration file switch on the logic in your application. Behavior in config files leads to a lack of maintainability and understanding, in my experience. I strongly prefer keeping configuration files as simple as possible.

---

I tend to agree with the premise of this question. I avoid getting myself into trouble by predicting early that this is going to happen, and therefore never roll my own config system.

• Either I use the operating systems' config facuility (such as a plist, or gconf or whatever is appropriate),
• Or a simple flat file, as can be handled by something like an off the shelf INI parser.
• Bite the bullet and plug a light weight language parser, usually lua, sometimes tcl into the application,
• Or store data in a SQLite or similar relational database.

And resign myself to live with whatever decision I made, or if i cant, refactor to use one of the above choices that better suits the application.

Point is, there's not really any reason to use a home-grown config solution. For one thing, it's harder on your users to have to learn a new, application specific config format. For another, You benefit from all the many bug-fixes and updates that come free when using an off-the-shelf solution. Finally, Feature creep is put to rest, because, well, you actually can't just add one more feature without really doing a major overhaul cause the config system isn't really in your hands in the first place.

---

It depends on what you agree with other developers on the team. Are you using config files just as config files or you are creating a Model Driven application.

Symptoms of config file becoming a programming language:

• name=value pairs start to depend on each other
• you feel a need to have flow control (ex. if (this) than that)
• documentation for config file becomes essential in order to do further development (instead of just using the application)
• before value from config is read it requires to have some context (i.e. values depend on something external to config file itself)

---

Config files invariably inch their way to becoming ugly, illogical "full fledged programming languages". It takes art and skill to design good programming languages, and config languages turned programming language tend to be horrendous.

A good approach is to use a nicely designed language, say python or ruby, and use it to create a DSL for your configuration. That way your configuration language can remain simple on the surface but in actually be the full fledged programming language.

---

I believe your question is very relevant given the move to "fluent interfaces". Many developers have "seen the light" with respect to XML configured applications. Using XML can be very verbose and difficult to edit correctly (especially if no schema is provided). Having a fluent interface allows the developer to configure the application in a domain-specific language with the assistance of some key-value pairs from a plain text configuration file (or perhaps command-line parameters). It also makes it very easy to setup and configure new instances of the application for testing or whatever.

Here are my answers to your question:

• What is the true purpose of a config file?

A config file is a way to allow the user to customize the behavior of their program at run-time.

• Should an attempt be made to keep config files simple?

Ideally, I would think that config files should at least be supplemented by a fluent interface to configure the program (this is useful in many respects). If you do require a config file then it should be kept very simple, nothing other than key-value pairs.

• Who should be responsible for making changes to them (developers, users, admins, etc.)?

I think the answer to this depends on your organization. It should be the responsibility of the person deploying the software to ensure that it is properly configured.

• Should they be source controlled (see question 3)?

I will steal this answer from someone else :) I like the idea of storing a template configuration in source control and modifying it for each local user's needs. Chances are one developer's config file is another developer's nightmare so it is best to leave things that vary by user out of source control. Having a template is also a nice way to let the person deploying the application (or other developers) see exactly what values are valid for the config file.

---

I have seen python programs where the config file is code. If you don't need to do anything special (conditionals, etc.) it doesn't look much different from other config styles. e.g. I could make a file config.py with stuff like:

num_threads = 13
hostname = 'myhost'

and the only burden on the user, compared with (say) INI files, is that they need to put '' around strings. No doubt you could do the same thing in other interpreted languages. It gives you unlimited ability to complicate your config file if necessary, at the risk of possibly scaring your users.

---

Yes, config files should be simple. They should contain no 'logic' themselves - think of them as a list of expressions in if statements, not the conditional statements in their entirety.

They're there to allow the user to decide which of the options coded within the application should be used, so don't try to make them complicated, it'll end up being self-defeating - you may end up writing simple config files to control how the original config file should be configured otherwise!

---

One of the purposes of the "Oslo" work at Microsoft is to permit (though not require) resolution of this issue.

1. An application would ship with models of any new components it includes. It would also use existing models. For instance, it might include a web service, so it could reuse the system model of a web service.
2. The models will include metadata describing them, including enough information for tools to access them, either textually or graphically.
3. Parts of the models will correspond to "configuration"

This means that the equivalent of todays configuration files may be rich enough to support both textual and graphical editing of their configuration. The graphical tool will be supplied with "Oslo" (code name "Quadrant").

---

I'll be the contrarian and submit it's only a language when it embodies more than can be represented by XML; or else when XML is considered to be a language.

Alternatively, most config files can be thought of as classes, but with only properties and no methods. And without methods, I don't think it's a language.

Ultimately, "language" is a squishy abstraction, but yes, the edges are ambiguous.

---

The code of our applications becomes less important... There is scripting, there are all kind of attributes that define the behaviour of classes, methods, method arguments and properties. Users can define database triggers and database constraints. There can be very complicated config files. Sometimes the user can define XSLT stylsheets to manipulate input and output because our systems need to be open (SOA). And there is stuff like BizzTalk that needs complex configuration too. Users can define complex workflows.

We have to write better code to deal with this complex environment, so the code of our applications becomes more important...

---

I'm a big fan of using python programs as config files, especially for daemons. I like to take the tack of making the daemon completely empty of configuration except for the "configuration port". The python program then connects to the daemon and proceeds to create objects in the daemon and wire them together to create the desired configuration. Once everything is set up, the daemon can then be left to run on it's own. The benefits, of course, are that you get a full fledged programming language to write your config files and since you already have a way to talk to the daemon from another program, you can use it for debugging and getting stats. The major downside is having to deal with messages from another program coming in at any time.

---

Config file: "What is my purpose?"
You: "Configure the butter."
Config file: "Ok..."
Config file: "What is my purpose?"
You: "You configure butter."
Config file: "Oh my god."

1. There is no "true purpose" of a configuration file. Its whatever makes sense for your application. In general, things that differ (or might differ) between machines and don't change in the middle of your application run should probably be in a configuration file. Defaults, ports, and addresses for other services are all great candidates. Keys and secrets are also great candidates but should be handled separately from your normal config for security reasons. I disagree that the purpose of a config file is to allow quick changes to be made. The purpose should be to allow flexibility in the setup of your application. If a config file is a quick easy to way to allow that flexibility, so much the better - but you should not be intending your config files to be frequently changing.

2. Yes and no. Should you atempt to make your application's code simple? Yes. You should attempt to make everything you write simple and to the point. No more complicated than it needs to be. Same is true of your config. However, this is very application specific. Hardcoding what should be in config because it would make your config "too complicated" is bad design. In fact, trying to "keep things simple" is why config files end up being a giant mess. Sometimes the simplest move is to modularize. This is why your configuration files should be written in a well known general purpose programming langauge - not some terrible configuration language (read: all "configuration languages" suck).

3. Again, who should be modifying config files is completely application dependent. But I agree with miniquark, whoever is deploying the application should be in charge of the configuration.

4. Source control everything you can. Source control is great. You can roll stuff back super easily and you have a full history of the changes you've made and a record of who made those changes. So why not?

참고URL : https://stackoverflow.com/questions/648246/at-what-point-does-a-config-file-become-a-programming-language