Re: [Draft] Pear web

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 :) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > CONVENTION for HTML widgets: > > > > |url: foo > > |------------------------------ > > web page | Text > > | > > |------------------------------ > > > > Input text |_______| > > > > Button |Text| > > > > Link _Text_ > > > > Check button |*| > > Huh? Plain text HTML widgets? :-) Isn't comfortable? :) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > USERS POINT OF VIEW (how the public web will look) > > > > url: pear.php.net/packages/ > > ------------------------------ > > search: |_______| > > > > Top Level Categories: > > > > _HTML_ > > _MAIL_ > > _DB_ > > _XML_ > > _NET_ > > 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! :) 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? > > |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? > > ------------------------------ > > > > 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. > > |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? > > ------------------------------ > > > > > > url: pear.php.net/packages/package.php?idpack=X > > ------------------------------ > > Net_NNTP-1.3 > > > > Authors: |photo :-)| > > Summary: > > Release Date: > > Release Notes: > > > > |View Doc| |View Source| |View Changelog| > > > > Net_NNTP dependencies: > > > > PHP > 4.0.2 > > PHP imap extension > > _Net_Foo-1.5_ |Download| |View Doc| |View Source| > > _Net_Ping-1.3_ |Download| |View Doc| |View Source| > > > > |Download all| |Download only Net_NNTP| > > > > Other releases download: > > _last cvs_ > > _1.2_ > > _1.1_ > > _1.0_ > > > > |Visit Net_NNTP users meeting point| > > Good stuff. Here, pkginfo.php can be used as a starting point (or > rewritten completely to use the PEAR_Package class). No problemo. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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? Tomas V.V.Cox