|
6
by mbp at sourcefrog
import all docs from arch |
1 |
YAML |
2 |
**** |
|
3 |
||
4 |
I am thinking about keeping changeset headers in YAML_, as a nice |
|
5 |
tradeoff: |
|
6 |
||
7 |
* Standard data format, so we don't need to invent, write and debug |
|
8 |
an ad-hoc format. |
|
9 |
||
10 |
* More concise than XML, which is useful if we're storing a few. |
|
11 |
||
12 |
* Reasonably readable for humans; thus suitable for sending in email |
|
13 |
and giving people at least some chance to read and understand it. |
|
14 |
Seeing this at the top of a patch would not be actively horrible as |
|
15 |
long as we keep it reasonably small; that's not true for XML. |
|
16 |
||
17 |
* Since YAML documents have a document header and terminator ('---'
|
|
18 |
and '...') we can pick them out of a text document and append |
|
19 |
text patches directly afterwards. |
|
20 |
||
21 |
* Fits well with Python internal data structures. |
|
22 |
||
23 |
* There are parsers for various languages, so people can write their |
|
24 |
own implementation if they really want. |
|
25 |
||
26 |
* There is space to specify a document format/version at the top |
|
27 |
(though this is not currently handled in ydump). |
|
28 |
||
29 |
The ydump module is pretty primitive, but it should have enough. |
|
30 |
||
31 |
.. _YAML: http://www.yaml.org/ |
|
32 |
||
33 |
||
34 |
Conclusion |
|
35 |
---------- |
|
36 |
||
37 |
On the whole, I think this is not a good idea. It is a nicer syntax |
|
38 |
for XML, but there are less bindings, and it does not achieve the goal |
|
39 |
of having the storage format look reassuring and giving confidence |
|
40 |
that the data could be retrieved by an alternative implementation. |