Re: [Draft] Pear web

["Tomas V.V.Cox" <cox@idecnet.com>] > I tried to write a minimal draft of the needed work to put the packages > distribution system up. If we could finish this draft and set up a small > team of developers we could start to build it. I make me volunteer to be > part of this team. Don't you? :) > > 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. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > CONVENTION for HTML widgets: > > |url: foo > |------------------------------ > web page | Text > | > |------------------------------ > > Input text |_______| > > Button |Text| > > Link _Text_ > > Check button |*| Huh? Plain text HTML widgets? :-) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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. > |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. > ------------------------------ > > 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? > |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. > ------------------------------ > > > 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). > ------------------------------ > > - View doc -> shows all the files marked as Role="doc", includes > READMEs, api doc, examples and other documentation > - View source -> link to cvs.php.net > - View changelog -> dinamicly generated changelog from release tags of > package.xml > - Download all -> the last release and dependencies > - Other releases -> cvs download from certain cvs tags (links generated > from releases in package.xml) > - Users meeting point -> Link to the authors page of the package, a > forum, etc. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > RELATED TASKS > > -Write the DEVELOPER POINT OF VIEW > -"package.xml" support for multiple authors > -"package.xml" support for multiple release tags > -"Install/Package" support for multi-package tar's > -finish the pear package local database (update/remove/list packages) > -implement package dependencies > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > PREDEFINED PACKAGES SETS > > We have been adviced by the problems of CPAN. One idea is to have > predefined sets of packages ready to install. > > url: pear.php.net/packages/core/ > ------------------------------ > > Core packages > > > |*| _Level 1_ recomendation |Download| > |*| _Level 2_ recomendation |Download| > |*| _Level 3_ recomendation |Download| > > |Download selected| |Download all| |Download required| > ------------------------------ > recomendation-> required, highly recomended, recomended, optional > > > url: pear.php.net/packages/core/level.php?idlevel=X > ------------------------------ > > Level 1 > > Contains: > > _XML_Parser_ summary > _Pear_DB_ summary > > |Download Level 1 packages| > ------------------------------ > > Each package correspond to one level. A package belong 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. :-) 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. - Stig -- Stig Sæther Bakken <ssb@alltheweb.com> Fast Search & Transfer ASA, Trondheim, Norway