1 |
On 25 June 2011 00:57, Nathan Phillip Brink <binki@g.o> wrote: |
2 |
> On Wed, Jun 22, 2011 at 08:57:47PM -0400, Wyatt Epp wrote: |
3 |
|
4 |
>> <cat> |
5 |
>> <tag>media</tag> |
6 |
>> <tag>video</tag> |
7 |
>> <tag>kde</tag> |
8 |
>> <tag>editors</tag> |
9 |
>> </cat> |
10 |
> |
11 |
|
12 |
I'm strongly of the mind that by making the tag system arbitrarily |
13 |
flat, you might be prematurely limiting yourself, as well as risking a |
14 |
future where the "tag index" is a sea of meaningless words. |
15 |
|
16 |
Tags in my mind, should be grouped by the sort of information they are |
17 |
trying to convey, as opposed to being arbitrary and completely |
18 |
un-grouped. |
19 |
|
20 |
The present category system only has one namespace, which is more or |
21 |
less "what-you-use-it-for", and if your tag system is likewise going |
22 |
to take that vector as the only approach, you will ultimately end up |
23 |
duplicating the category system, albeit without the present limitation |
24 |
that means one package can only exist in one place. |
25 |
|
26 |
This need not be the case, we can suggest alternative tag namespaces, |
27 |
such as : The sorts of files it supports working with, the sorts of |
28 |
things it can read, the sorts of things it can write. |
29 |
|
30 |
At present, things that migrate one type of media to another, such as |
31 |
pdf -> image , image -> pdf, image -> video , video -> images , etc |
32 |
have to be forced to a sort of useless categorisation system. |
33 |
|
34 |
However, if via tag data, we were able to annotate a) what can be |
35 |
written and b) what can be read, this system could be leveraged to |
36 |
epic proportions of win. |
37 |
|
38 |
tag-lookup --supporting $( file ./foo ); |
39 |
.... |
40 |
Read/Write: |
41 |
foobarnator - Blah blah blah |
42 |
Read: |
43 |
foo-bar - Blah blah |
44 |
foo-bjaz - Blah blah blah |
45 |
Write: |
46 |
a2foo - Blah Blah |
47 |
|
48 |
|
49 |
tag-lookup --verbose --supporting $( file ./foo ); |
50 |
.... |
51 |
Read/Write: |
52 |
foobarnator - Blah blah blah |
53 |
- reads x , y , z , foo |
54 |
- writes a, b, c, foo |
55 |
Read: |
56 |
foo-bar - Blah blah |
57 |
- reads foo |
58 |
- writes text |
59 |
foo-bjaz - Blah blah blah |
60 |
- reads foo, bar |
61 |
- writes text, mp3 |
62 |
Write: |
63 |
a2foo - Blah Blah |
64 |
-reads mp3, png, jpeg |
65 |
-writes foo |
66 |
|
67 |
|
68 |
As a side note, it may be beneficial to tag a package version |
69 |
specifically for some of the above mentioned features. Especially if |
70 |
you wish to support my "provides-binary" suggestion, because the |
71 |
shipped binary may change from one version/slot to another. |
72 |
|
73 |
I'm not sure if there's a way to provide data on a per-version level |
74 |
yet in Metadata.xml, but I am assuming there's not as I don't see it |
75 |
documented. |
76 |
|
77 |
<pkgmetadata> |
78 |
<versionspecific> |
79 |
<slot>2</slot> |
80 |
<pkgmetadata> |
81 |
... normal stuff |
82 |
</pkgmetadata> |
83 |
</versionspecific> |
84 |
<versionspecific> |
85 |
<maxversion>1.0</maxversion> |
86 |
<maxversion>1.999</maxversion> |
87 |
<pkgmetadata> |
88 |
... normal stuff |
89 |
</pkgmetadata> |
90 |
</versionspecific> |
91 |
</pkgmetadata> |
92 |
|
93 |
|
94 |
Or something similar. |
95 |
|
96 |
|
97 |
|
98 |
-- |
99 |
Kent |
100 |
|
101 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
102 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
103 |
|
104 |
http://kent-fredric.fox.geek.nz |