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