| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Stroller wrote: |
| 5 |
> |
| 6 |
> On May 12, 2005, at 10:11 am, Patrick Lauer wrote: |
| 7 |
> |
| 8 |
>> On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote: |
| 9 |
>> |
| 10 |
>>> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote: |
| 11 |
>>> |
| 12 |
>>>> |
| 13 |
>>>> * Unique ID strings for packages, zynot style. Messy as hell though, |
| 14 |
>>>> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have |
| 15 |
>>>> the same kind of ring to it... |
| 16 |
> |
| 17 |
> |
| 18 |
> I'm going to ignore that. This thread started because the current |
| 19 |
> category/name naming convention causes interesting conditions. I |
| 20 |
> appreciate that generally Microsoft Are Not Our Favourite Software |
| 21 |
> Company, but giving them as an example doesn't inherently make unique |
| 22 |
> IDs bad, and 128-bit ones are not necessary in this case. |
| 23 |
> |
| 24 |
32-bit (unsigned) should be plenty ;) |
| 25 |
> |
| 26 |
>>> It prevents upstream naming collisions |
| 27 |
>> |
| 28 |
>> But reduces readability for humans to zero. We don't want that. |
| 29 |
> |
| 30 |
> |
| 31 |
> Humans are used to dealing with indexes - we remember phone numbers |
| 32 |
> easily, and if we're looking up several things in a large volume, then |
| 33 |
> we're used to using bookmarks or noting down page numbers. A six figure |
| 34 |
> decimal packageID allows for a million packages in the Portage tree (and |
| 35 |
> I'm assuming versions will be separate, anyway), a five figure hex ID |
| 36 |
> would allow far more. |
| 37 |
> |
| 38 |
>> At least you haven't tried to optimize it all by using XML ... |
| 39 |
>> |
| 40 |
>>> but the rest of us will use |
| 41 |
>>> `esearch -o "%p\n" "" | grep -e category -e keyword`. |
| 42 |
>> |
| 43 |
>> *head explodes* |
| 44 |
>> No. |
| 45 |
I think there are a few points that are at the core of this. |
| 46 |
A. Categories are metadata. Not many people like doing this, |
| 47 |
especially since you are sorting by a particular metadata that isn't |
| 48 |
unique in all cases ( or shouldn't be ). If people want to sort by |
| 49 |
something else, it too should be unique, hence the GUID crap above. |
| 50 |
This might kill off names ( do we not want a package have 2 names, or 2 |
| 51 |
packages having the same name? ). |
| 52 |
|
| 53 |
B. Users don't care how the data is stored, they will create/use tools |
| 54 |
to search through it. I think this is much different than the |
| 55 |
developer's view. As a user, if I am looking for a package I'll use |
| 56 |
emerge -s or p.g.o. I don't go diving into the tree unless I'm looking |
| 57 |
for an ebuild and I doubt that many users actually go ebuild diving. |
| 58 |
This creates issues where developers need to get to ebuilds to check out |
| 59 |
issues, and users want fast searching. One is condusive to human |
| 60 |
readability, the other is to computer readability. |
| 61 |
|
| 62 |
Is human readability worth it here, and is there a storage mechanism |
| 63 |
that gives us both? Certainly the current system works, albeit with |
| 64 |
some limitations that some people do not like. IMHO I think the flat |
| 65 |
tree sucks too, but I haven't put much thought into any other storage |
| 66 |
mechanism. Certainly it would be nice if one machine held the database |
| 67 |
on a SQL server and each client just made queries, although it would be |
| 68 |
much slower :) |
| 69 |
|
| 70 |
I should also note that ripping categories out of CPV's means a lot of |
| 71 |
work on internals; I think it's worth it to spec things out now since a |
| 72 |
lot of other stuff is being gutted anyway. |
| 73 |
|
| 74 |
- -Antarus |
| 75 |
|
| 76 |
> Stroller. |
| 77 |
> |
| 78 |
-----BEGIN PGP SIGNATURE----- |
| 79 |
Version: GnuPG v1.4.1 (GNU/Linux) |
| 80 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 81 |
|
| 82 |
iQIVAwUBQoNDzGzglR5RwbyYAQJaVQ//ZsFJzSkm35bo87SAwUqtWKjOvOn6CUph |
| 83 |
2vdOfnjIjJQkhgeew8RMp/f+TiKuCT8t0WVtTKsS5mLeno2WXkqetbfVayfsT29L |
| 84 |
kMqp42LUDPBEHe+aOMn8TlKjCvPpNow4TWecFEoaV6MF4sutxyP3+cg6Noay7hiF |
| 85 |
mvGahADLpuENNaLpmy0ETs6oh4UeReI6PBl6QrO46uj9kL3HnFxPRncp+52Q0KHh |
| 86 |
44uoqcGu4PYF5YfTHqyA71Ibg9SPKPUGxHbs53ISVmhWRWuRs6l+3N7aXyap5ChV |
| 87 |
iBMsAzns0xMAuV25BoPTmdyQSyJBAXfXCtAWJ0PcFRx5lnMvVJ95McXjjeINbG60 |
| 88 |
dWJQ1q1CKeOIVnm6JScwtkELm1yXIKnQ8wqpSevC+xrNUwJCth/g6pHvSPZhw9ng |
| 89 |
R6nTpwd8DWwUJ7j90L7Aggf2vB2+f/u2c03er120PKiAMJIJtLXHJlLrkGH8/MkT |
| 90 |
F1fol4TF4i4sLXJ+kceoOFHEgT70kmQXpdzTMfhcm3BAIBxTDGkjWS5+U+3K3wCj |
| 91 |
3fgxm/28B9b396cdoXWDOgV9C1kEe1IkC+GKe6CmFqIiP70Ov4eGgj3ejSabY5YV |
| 92 |
OWiPKMeLPjZtL5H4359k6S2U42zJI9BJUoJgFP9iQhhMA8Io+GLKVwwv+5Jd+V9l |
| 93 |
BoHjO7tPWmw= |
| 94 |
=nJ6R |
| 95 |
-----END PGP SIGNATURE----- |
| 96 |
-- |
| 97 |
gentoo-dev@g.o mailing list |
Archives