Re: Re: Version naming

Alan Knowles wrote:

I did test this over 6 months ago - the mail is on the pear-core archives modifying the packager to create {package}-{version}-{state}.tgz was a few lines of code. in PEAR/Packager.php - function package() // {{{ TAR the Package -------------------------------------------

       $ext = $compress ? '.tgz' : '.tar';
       $dest_package = getcwd() . DIRECTORY_SEPARATOR . $pkgver . $ext;

// {{{ TAR the Package -------------------------------------------

       $ext = $compress ? '.tgz' : '.tar';
       $dest_package = getcwd() . DIRECTORY_SEPARATOR . $pkgver . '-' . $pkginfo['release_state'] . $ext;

the pear web site, however renames the file when you upload it.. (I dont dont see this as a problem, who cares how the pearweb stores the filenames internally.) - the only place I can see it being benifitial to use the long name is when you manually download the file to install it.. (without using the pear packager) I'm not sure how much is involved - but I would assume it probably just a matter of adding a Content-type: filename=..... to the dowload page. (and re-appending the same info there..) From what I remember, there is almost no place in pear that should depend on the filename.. - the package xml is used in all places??. (although package spoofing comes to mind a bit..) Is it really that complex? - it's a while since I dug that deep into the packager.

The complexity for PEAR 1.3 was all on the pearweb side. With the advent of channels, it has become apparent that duplicating pearweb's xml-rpc interface is ridiculously complex, and with the current system, it will be possible to implement a pearweb server that has literally no code, only symlinks. Adding in this option makes it a lot more complex to handle on the client side and the server side. Why? The system for determining what to ask for is as follows: 1 - is it a local file? 2 - is it a remote static url? 3 - is it a random string?

    a - use parse_url() to extract components of potential channel://channel.name/packagename[-version|-state][.ext][#group][?opt1=blah]
    b - if present, check the stuff after '-' to see if it is a valid state, if not, see if it is a valid version
    c - once the string has been parsed, use package.getDownloadURL() to retrieve the url to download a package.

On the server side, getDownloadURL() takes 3 args, the package name, a version/state string, and the preferred_state config var. In case you're wondering, using getDownloadURL() has many important side effects, the most obvious of which is that you can return the link to the latest release on an error, and you can transparently pass in a mirror's url for download. Even better, it makes possible complete dependency resolution prior to download, which speeds up invalid downloads by a factor of 10 even with a cable modem, the speedup on dialup will be in the factor of 100s or better. To do any server-side renaming magic requires mod_rewrite and a magic "get" file with php code in it. When setting up the current incarnation of PEAR_Server, I found it extremely difficult to configure my own code (!) because of the complexity of setting up the mysql database. Recently, it came to my attention that a uri-based solution to the problem would be far more effective, because it would only require the use of symlinks or copying files manually. The load on the server would be minimal, the speed would be blistering since everything would be served up through regular http, and so on. Allowing -version-state and -state-version (since both would need to be supported for annoyance factor reasons) would double the number of symlinks needed, and in fact to create informative error messages would in fact more than quintuple the number of links needed because every invalid state (1.0.0-devel, 1.0.0-alpha, etc.) would need to be there so that it could return error information ("1.0.0-devel does not exist, 1.0.0-stable does, however") If we implement this new "feature" I guarantee it will simply limit the growth of other PHP channels due to the complexity of setting up a server, even with automated tools, and will introduce a whole plethora of new bug possibilities that would need to be tested, which will delay the release of PEAR 1.4 for at least a month, maybe 2. For these reasons, I see the disadvantages far outweighing any benefits, at least until PEAR 1.4.0 as it currently stands is tested and released. However, if there were any real team working on the installer, it might be possible to do this. As it stands, the idea of a team is laughable - I've had several people approach with interest in helping who have been unable to find enough interest to take away time from their other pursuits to follow through. As well-intentioned as it is, there's no team right now beyond me working on this stuff. It's fun to think up ideas, but it is very tedious to actually implement them with any semblance of stability and completeness :). Greg