it-swarm.dev

Dlaczego XML dla plików konfiguracyjnych?

Dlaczego tak wiele projektów używa XML do plików konfiguracyjnych?

43
Omry Yadan

Dzięki za odpowiedzi . To pytanie, na pierwszy rzut oka naiwne, na pierwszy rzut oka nie było takie naiwne :)

Osobiście nie lubię XML dla plików konfiguracyjnych, myślę, że ludziom trudno jest czytać i zmieniać, a komputerom trudno jest analizować, ponieważ jest tak ogólny i potężny.

Pliki INI lub pliki Java są odpowiednie tylko dla najbardziej podstawowych aplikacji, które wymagają zagnieżdżania . wspólne rozwiązania do dodawania zagnieżdżenia do tych formatów wyglądają tak:

level1.key1=value
level1.key2=value
level2.key1=value

nie jest to ładny widok, dużo nadmiarowości i trudno przenosić rzeczy między węzłami.

JSON nie jest złym językiem, ale został zaprojektowany tak, aby był łatwy do przetwarzania przez komputery (jest to poprawny JavaScript), więc nie jest używany do plików konfiguracyjnych.

JSON wygląda tak:

{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}
    ]
  }
}}

Moim zdaniem jest zaśmiecony przecinkami i cudzysłowami.

YAML jest dobry dla plików konfiguracyjnych, oto przykład:

invoice: 34843
date   : 2001-01-23
bill-to: &id001
    given  : Chris
    family : Dumars

jednak zbytnio nie podoba mi się jego składnia i myślę, że użycie białych znaków do zdefiniowania zakresów powoduje, że rzeczy stają się nieco kruche (myślę, że wklejanie bloku na inny poziom zagnieżdżania).

Kilka dni temu zacząłem pisać własny język dla pliku konfiguracyjnego, nazwałem go Swush .

Oto kilka przykładów: Jako proste pary klucz-wartość:

key:value
key:value2
key1:value3

lub jako bardziej złożony i skomentowany

server{
    connector{
         protocol : http // HTTP or BlahTP
         port : 8080     # server port
         Host : localhost /* server Host name*/
    }

    log{
        output{
             file : /var/log/server.log
             format : %t%s
        }
    }
}

Swush obsługuje ciągi znaków w powyższym prostym formularzu lub w cudzysłowie - co pozwala na wstawianie białych znaków, a nawet znaków nowej linii wewnątrz łańcuchów . Wkrótce dodam tablice, takie jak:

name [1 2 b c "Delta force"]

Istnieje implementacja Java, ale mile widziane jest więcej implementacji. :) . sprawdź stronę, aby uzyskać więcej informacji (większość z nich omówiłem, ale API Java udostępnia kilka interesujących funkcji, takich jak selektory)

9
Omry Yadan

To ważne pytanie.

Większość alternatyw (plików JSON, YAML, INI) jest łatwiejsza do analizowania niż XML.

Również w językach takich jak Python - gdzie wszystko jest źródłem - łatwiej jest po prostu umieścić swoją konfigurację w wyraźnie oznaczonym module Pythona.

Jednak niektórzy ludzie twierdzą, że XML ma pewną przewagę nad JSON lub Pythonem. 

Najważniejsze w XML jest to, że „uniwersalność” składni XML nie ma zbyt dużego zastosowania przy pisaniu pliku konfiguracyjnego specyficznego dla aplikacji. Ponieważ przenośność pliku konfiguracyjnego nie ma znaczenia, niektórzy ludzie w Pythonie zapisują swoje pliki konfiguracyjne w Pythonie.


Edytować

Bezpieczeństwo pliku konfiguracyjnego nie ma znaczenia. „Konfigurowanie programu Python w Pythonie jest argumentem bezpieczeństwa” wydaje się ignorować fakt, że Python jest już zainstalowany i działa jako źródło. Po co pracować w złożonym hacku w pliku konfiguracyjnym, gdy masz źródło? Po prostu włam źródło.

Słyszałem, że ludzie mówią, że „ktoś” może zhakować twoją aplikację za pomocą pliku konfiguracyjnego. Kim jest ten „ktoś”? Administrator? DBA? Deweloper? Nie ma wielu tajemniczych „kogoś” z dostępem do plików konfiguracyjnych.

A każdy, kto mógłby włamać się do pliku konfiguracyjnego Pythona w niecnych celach, mógłby prawdopodobnie zainstalować keyloggery, fałszywe certyfikaty lub inne poważniejsze zagrożenia.

39
S.Lott
  1. XML jest łatwy do przeanalizowania. Dostępnych jest kilka popularnych, lekkich, funkcjonalnych i/lub darmowych bibliotek analizujących XML w większości języków.
  2. XML jest łatwy do odczytania. Jest to bardzo czytelny język znaczników, więc łatwo jest pisać zarówno ludziom, jak i komputerom.
  3. XML jest dobrze określony. Wszyscy i jego pies wiedzą, jak pisać przyzwoity XML, więc nie ma wątpliwości co do składni.
  4. XML jest popularny. Gdzieś po drodze niektórzy Important People ™ zaczęli popierać ideę, że XML jest „przyszłością” i wielu ludzi go kupiło.
  5. XML jest formatem dwukierunkowym. Oznacza to, że zachowane są białe znaki, komentarze i porządek. Możesz programowo załadować, zmienić, a następnie zapisać go, zachowując formatowanie. Jest to ważne dla narzędzi, których użytkownicy mogą używać do konfigurowania swoich aplikacji. Jest to jeden z powodów, dla których XML został pierwotnie uruchomiony (świat stał się bardziej techniczny, więc jest to mniej potrzebne).
  6. XML ma opcjonalną walidację schematu. Ważne dla narzędzi i złożonych formatów konfiguracji.
  7. XML ma przestrzenie nazw. Pozwala to na osadzanie innych konfiguracji lub adnotacji bez wpływu na parsowanie. W innych formatach konfiguracyjnych jest to zazwyczaj wykonywane ze specjalnymi komentarzami hackowania lub manglingiem nazw właściwości.

Na marginesie, nie próbuję bronić XML. Ma swoje zastosowanie i będę go używał w projekcie, gdy tylko wrócę do tego. Jednak w wielu przypadkach, a zwłaszcza w plikach konfiguracyjnych, jedyną zaletą jest to, że jest to standardowy format i myślę, że jest to znacznie przeważone przez wiele wad (tj. Jest zbyt gadatliwy). Jednak moje osobiste preferencje nie mają znaczenia - odpowiadałem tylko, dlaczego niektórzy ludzie mogą wybrać XML jako format pliku konfiguracyjnego. Ja osobiście nigdy tego nie zrobię.

30
Chris Lutz

Ponieważ XML brzmi fajnie i przedsiębiorczo.

Edytuj: Nie zdawałem sobie sprawy, że moja odpowiedź była tak niejasna, dopóki komentator nie zażądał definicji przedsiębiorczości. Cytowanie Wikipedii :

[...] termin „przedsiębiorczość” ma wykraczać poza problem „przesady dla mniejszych organizacji”, sugerować, że oprogramowanie jest zbyt złożone, nawet dla dużych organizacji i dostępne są prostsze, sprawdzone rozwiązania.

Chodzi mi o to, że XML jest modnym słowem i jako taki jest nadużywany. Pomimo innych opinii, XML nie jest łatwy do analizy (wystarczy spojrzeć na libxml2, jego pakiet źródłowy z gzipem ma obecnie ponad 3 MB). Ze względu na ilość nadmiarowości pisanie ręczne jest również irytujące. Na przykład, Wikipedia wymienia konfigurację XML jako jedną z przyczyn spadku popularności jabberd na korzyść innych implementacji.

23
avakar

XML jest dobrze rozwiniętym i przyjętym standardem, dzięki czemu jest łatwiejszy do odczytania i zrozumienia niż zastrzeżone formaty konfiguracji. 

Warto również zrozumieć, że serializacja XML jest popularnym narzędziem dostępnym w większości języków, co sprawia, że ​​zapisywanie danych obiektów jest niezwykle łatwe dla programistów. Po co budować własny sposób zapisywania hierarchii złożonych danych, gdy ktoś inny wykonał już za ciebie pracę?

.NET: http://msdn.Microsoft.com/en-us/library/system.xml.serialization.aspx

PHP: http://us.php.net/serialize

Python: http://docs.python.org/library/pickle.html

Java: http://Java.Sun.com/developer/technicalArticles/Programming/serialization/

13
Robert Venables

Inną kwestią jest to, że jeśli masz XSD (plik schematu) do opisania pliku konfiguracyjnego, to dla twojej aplikacji sprawdzenie poprawności pliku konfiguracyjnego jest banalne.

8
JonnyBoats

Ponieważ parsowanie XML jest stosunkowo łatwe i jeśli schemat jest jasno określony, każde narzędzie może łatwo odczytywać i zapisywać informacje.

3
Stefano Borini

Cóż, XML jest specyfikacją ogólnego przeznaczenia, która może zawierać opisy, zagnieżdżone informacje i dane o czymś. Istnieje wiele interfejsów API i oprogramowania, które mogą je analizować i czytać.

Łatwo więc opisać coś w sposób formalny, znany jako platformy krzyżowe i aplikacje.

2
Saleh Al-Zaid

Oto kilka powodów historycznych:

  • W3C przeniósł się z budowania narzędzi w Perlu na Javę
  • Fundacja Apache przeniosła się z budowania narzędzi w Perlu na Javę
  • Java ma wiele XML ​​API
  • Konfigurację można zatem wykonać w Javie
  • Konfiguracja przez XML i pliki właściwości dla programistów innych niż Java

JTidy configuration vs tidy configuration jest najlepszym tego przykładem.

1
Paul Sweatte

Jednym z powodów, które nie zostały określone w innych odpowiedziach, jest kodowanie Unicode/tekst/nazwij je. Potrzebujesz chińskiego ciągu w pliku? Nie ma problemu. Może to brzmieć trywialnie, ale gdy wprowadzono XML, nie było. Oczywiście nie w plikach INI.

Inna rzecz - była to pierwsza rzecz, która dała nam możliwość posiadania uporządkowanych danych z listami, słownikami lub czymkolwiek, co można obrabiać i edytować w tym samym czasie.

Ma wady, ale czego jeszcze możesz użyć? Yaml wygląda świetnie, ale boję się go wprowadzić w projektach, nad którymi pracuję, ponieważ po prostu widzę w mojej wyobraźni wszystkie te problemy z ludźmi umieszczającymi białą przestrzeń w niewłaściwym miejscu lub łączącymi narzędzia nie dbające o nich.

0
Arek

Główną zaletą XML i powodem, dla którego jest on tak popularny, jest to, że jest popularny w świecie Java, dlatego wszystkie aplikacje korporacyjne napisane w Javie używają go, a także dlatego, że usługi sieciowe i mydło są oparte na xml i te są często używane aplikacje korporacyjne.

Jak dotąd JSON i wszystkie inne formaty nie są tak dobrze obsługiwane przez branżę, z wyjątkiem aplikacji ajax. Ponadto JSON nie ma języka schematu ani zdefiniowanego interfejsu API do analizowania, takiego jak XML.

Nawet jeśli z grubsza rzecz biorąc, JSON nie potrzebuje ton rzeczy, które xml ma, przynajmniej nie w ten sam sposób, a ja mówię w serwisach internetowych, kiedy mówię ...

0
Coyote21

Jest to spowodowane tym, że XML pozwala zasadniczo tworzyć własne znaczniki semantyczne, które mogą być odczytywane przez parser zbudowany w praktycznie dowolnym języku. Dodatkową korzyścią jest to, że plik konfiguracyjny zapisany w języku XML może być używany w projektach, w których używasz dwóch lub więcej języków. Jeśli miałbyś stworzyć plik konfiguracyjny, w którym wszystko zdefiniowano jako zmienne dla określonego języka, to oczywiście działałoby to tylko w tym języku.

0
teh_noob