Re: [Draft] Pear web

["Tomas V.V.Cox" <cox@idecnet.com>] > Stig Sæther Bakken wrote: > > > > ["Tomas V.V.Cox" <cox@idecnet.com>] > > > > > > I would recommend to people who wants discuss an specific area of this > > > doc, to open a new thread, so we won't get crazy tracking different > > > topics. > > grrrr :) Heh, guess who missed this paragraph? ;-) I'll be nice and split after this one. > > There's a script for browsing the package space already > > (pearweb/public_html/packages.php), but it needs better HTML layout > > and such. > > Wow! The Pear web is plenty of stuffs and you haven't say nothing! :) Stealth software development. I guess most of the stuff there should be readable. Maybe the "visitation" stuff needs some explaining, it's a method for representing trees efficiently with SQL (it lets you determine the number of "children" a node (package in our case) has very easily). See the comment before visit_node() in include/pear-database.php for more visitation tricks. > For my tests I did a "make create" under pearweb/sql, but the tables > there, are not the same as the ones at pear.php.net :-? What am I doing > wrong? Probably because the database on pear.php.net is a bit old, I'll do a round of "make destroy" and "make create". > > > |Download all packages| > > > > For downloading more than one package at once, we need a bundling > > mechanism. Maybe use a different extension, such as .mtz for > > "multiple tar/gz files", and then the installer can handle the rest. > > Very easy to detect, good idea. The format? A simple tar with tgz's? Or > should we build a meta-data xml file describing its contents also? We could define a generic "manifest" (file listing++) XML format for both the .tgz and .mtz files, since the tar format does not have such an index. This should wait until the installer uses a built-in tar implementation though. > > > ------------------------------ > > > > > > url: pear.php.net/packages/category.php?idcat=X > > > ------------------------------ > > > search: |_______| > > > > > > NET category > > > > > > Packages: > > > > > > |*| _Net_CheckIP-1.1_ summary > > > |Download| |View Doc| |View Source| > > > |*| _Net_NNTP-1.3_ summary > > > |Download| |View Doc| |View Source| > > > |*| _Net_Ping-1.4_ summary > > > |Download| |View Doc| |View Source| > > > > Wouldn't this just be part of the "package space" browser? > > When I enter to a site for the first time I click every where, but when > it's my 100th time I prefer direct access to things. With this and two > clicks I could check the doc on-line, quick download what I know that > need or check the source. And why not, we have enought empty space > there. You're right. But we don't need to add the term "category" into this. > > > |Download all "Net" packages| |Download selected packages| > > > > > > Leyend: > > > - Red packages means Experimental State > > > > Using colors is a good idea, but we need more than just > > "experimental". At least "stable" releases should be easily visible > > as such, and I'd like to see "alpha", "beta" and > > "development" or > > "snapshot" states too. > > Make standar package state flags in the package.xml would help a lot > (ie. <Package State="">). Or was selected a convention yet? Whoops! State is an attribute of a _release_, not of the package itself. For example, if "DB 2.x" is under development, the 2.0 pre-releases will be labelled experimental or whatever, while the 1.x releases are stable. > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > PREDEFINED PACKAGES SETS > > > > > > We have been adviced by the problems of CPAN. One idea is to have > > > predefined sets of packages ready to install. > > > > [..] > > > Each package correspond to one level. A package belongs a certain level > > > according to: is used by lot of other packages and/or is a > > > popular/widthly used package. We could also give recomendations to > > > ISPs/users/developers that levels from 1 to 3 are required, from 4 to 6 > > > highly recomended, etc. > > > > At this point, I think we should restrain ourselves to define _one_ > > core set, the "PHP Foundation Classes" or something like that. Such > > as set of packages would need a lot of rigorous interoperability > > testing, and we can't expect to be able to maintain multiple "levels" > > on top of that until there is a company willing to pay someone to work > > full-time with PEAR QA. :-) > > Umm... yeah, seems to have more sense at least viewing the actual pear > state. Any way we could re-think things in the future. I'm sure the "php > foundation classes" (I'd prefer "pear foundation classes") will be the > most downloaded thing from the web. > > > We need a test environment for the web site. What about using > > pear.php.net and displaying the "in-development" stuff only when the > > browser sends a "pear-dev" cookie? Me fix. > > For those of you who don't imagine what Stig means with a "pear-dev > cookie", try: http://pear.php.net/?devme > > At least for me is a little bit complicated to build a web from cvs: > wait checkouts, no access to database console, no nice shell access. > Isn't there an other more comfortable solution? Mail me a des-encrypted password string and your ssh1 key if you have one and I'll set up an account for you on the box. - Stig -- Stig Sæther Bakken <ssb@alltheweb.com> Fast Search & Transfer ASA, Trondheim, Norway