1 |
"Alec Warner" <antarus@g.o> writes: |
2 |
|
3 |
> Diego, What are the concrete benefits of your proposal? |
4 |
|
5 |
As I said: |
6 |
|
7 |
- no need to replicate homepage data between versions; even though forks |
8 |
can change homepage, I would expect that to at worse split in two a |
9 |
package, or have to be different by slot, like Java; |
10 |
- allows proper handling of packages lacking a HOMEPAGE; |
11 |
- less data in metadata cache; |
12 |
- users can check the metadata much more easily by just opening the xml |
13 |
file or interfacing to that rather than having to skim through the |
14 |
ebuild, the xml files are probably more user readable then ebuilds |
15 |
using multiple eclasses; |
16 |
- displaying info about the package does not require parsing the full |
17 |
ebuild file, with its eclasses; |
18 |
- extensible to provide more links than just the homepage (forums, |
19 |
trackers, gentoo-specific documentation, ...); |
20 |
- if we also move DESCRIPTION, search software can ignore everything |
21 |
about ebuild parsing, and just use the metadata.xml files; considering |
22 |
how many people actually use or used eix, it would make sense to allow |
23 |
third-party applications to be able to search through the tree; |
24 |
- webapps like packages.gentoo.org would be able to display basic |
25 |
information without having to parse the ebuilds or the metadata cache. |
26 |
- as much as people might think metadata is easier to parse than |
27 |
anything, XML has one huge advantage: there are plently of parsers for |
28 |
any language without having to actually write one, even as easy as it |
29 |
can be, and it's easily interfaced with anything; I wrote a simple XSL |
30 |
file that outputs the basic metadata details for packages without |
31 |
having any parser or executable code but xsltproc (or any other XSLT |
32 |
software), correlating data with herds.xml too; |
33 |
- it really is metadata, and it makes very little sense to need parsing |
34 |
of eclasses and EAPI handling to get some data from a package that is |
35 |
non-functional in nature and free form (just like DESCRIPTION, and |
36 |
unlike LICENSE like Alec said), and that changes at worse once each |
37 |
slot (unlike LICENSE that can change at any given version). |
38 |
|
39 |
Disadvantages: |
40 |
|
41 |
- it requires user-interface software to parse metadata.xml to show |
42 |
data for a package; which is already needed to show per-package USE |
43 |
flag meaning; |
44 |
|
45 |
General points: |
46 |
|
47 |
- it does not solve unrelated problems like code replication; |
48 |
|
49 |
Can someone come up with any other point beside "I don't like XML" |
50 |
(which I already said is a puny answer) and "it can theorically be 10 |
51 |
different homepages for 10 different versions" (which I have sincerely |
52 |
some beef with myself since if you fork a software you might as well |
53 |
change its name)? |
54 |
|
55 |
As I said, moving out the HOMEPAGE field from a package manager |
56 |
prospective is non functional; if you're showing to the user some data |
57 |
about a package you might as well show as much as you can, like long |
58 |
descriptions, other links, and USE flags. And the fact that you can ask |
59 |
the package manager for something is for me not a valid reason to avoi |
60 |
moving something in a more approchable place for other software. |
61 |
|
62 |
-- |
63 |
Diego "Flameeyes" Pettenò |
64 |
http://blog.flameeyes.eu/ |