Re: Re: Categories

Stig Sæther Bakken wrote: > > > > > >Their > > > only purpose is to provide categorization primarily for us humans, the > > > names and structure of the packages themselves is slightly different. > > > > Well, category names are human friendly, but IMHO still we need to map > > 1:1 "human categories" with "packages name spaces". > > > > Category -> Dir > > --------------------- > > Databases DB > > Foobiscus Foo > > > > If not, we will end with a package Bar in category "Network" but > > installed in directory XML/Net (for saying something). I see a mess in > > the horizon :-) > > IMHO this isn't realistic. "DB" is a database abstraction layer. You > can't require any database-related package to be called DB_something. > Since PEAR is going to let packages with similar functionality > co-exist, it just can't be 1:1 between "package spaces" and > categories. DB is Database, if not why your DB_storage is there? :-) If we have now classes ordered by "topic" why not only transform these topics to a human redeable form (this is categories)? This way always will be realistic. > > > A "Forms" top-level category would probably be what we needed if there > > > is XML form stuff coming too. > > > > Top-level? Please explain me why top level and not sub-category of HTML. > > What if someone makes an "über-forms-package" that deals with HTML, > XHTML, WML and PDF/FDF? :-) > Ah, ok, ACK :). But as far as we can IMHO we should minimize the number of categories to never overcome 10-15 per level. Tomas V.V.Cox