> From: Greg Beaver [mailto:[EMAIL PROTECTED] > > Both phar/PHP_Archive and PHK support this. The only file > format that would "allow" this kind of shebang is the tar > file format, as the first element in the file is a filename. > The original design of PHP_Archive used the tar file format > to take advantage of this hack.
So, if we want to base our format on tar, we will have to put a file with an exotic name as first element. As, anyway, the package file cannot be written via the tar command (because of this ugly first file, and probably because we'll want the next file to be a binary/serialized file map), I don't see a big benefit there. > I mean a public RCS like a CVS or SVN server. I found the > PHK_Creator package and looked at it in order to review the > source code. Yes, I'd like to store it on such a server. But I don't know these systems very well. I planned to put it on sourceforge but I didn't have enough time yet. > This is exactly how phar/PHP_Archive works. For example: > http://pear.php.net/go-pear.phar contains the complete > PHP_Archive class, which will fall back to the phar extension > if available. But you say in the doc that the stub can contain any code terminated by an __halt_compiler(); ? I don't understand. If a phar archive is generated by the phar extension, it does not include the PHP_Archive runtime code, right ? So, it cannot run without the phar extension installed. Am I wrong ? > I am probably unclear with my argument here. After a deep > review of the source code, it seems to me that PHK is > basically PHP_Archive with a different file format plus a few > built in extras and a separate website. In other words, at > the time you started the PHK project, PHP_Archive was fully > functioning (version 0.6.0, released on 2005-08-30) and was > backed by the officiality of being served from PEAR, a > php.net site. Rather than attempt to inject your interesting > ideas for the future of PHP_Archive, you seem to have > actively avoided PHP_Archive and re-invented the wheel. Actually, there is a reason, PHK was not the first step... The first step was the autoloader. When it was ready, I started thinking of a sort of jar feature for PHK. So, of course, I looked at PHP_Archive to see if I could integrate my autoloader. But, at this time (end 2005), there was not much documentation and the first tests showed that the PHP_Archive'd package checked if it was run as 'main file'. When I tried to include it, I got an error message saying that it had to be the first script to run. So, as I wanted to make library packages, I started a small project which became PHK, without 'actively avoiding' PHP_Archive. I also must say that, yes, I tend to consider that a project whose only documentation is the source code is not a good development base. Maybe it is too theoritical but, IMO, a project without any doc is not 'fully functioning' :) Now, PHP_Archive has evolved into phar and, yes, PHK provides almost every features present in phar. But, where I disagree, is when you say that it just add 'a few built in extras and a separate website'. If you look at the code, you will see that these 'few built-in extras' represent more than 80 % of the product. I think the difference here is the way we consider these 'built-in extras'. I try to consider them from a non-expert point of view, and I try to imagine what can convince and/or seduce an average user. So, by providing demo packages, building kits, and an extensive documentation, I try to solve the problems a newcomer can meet. This is the way I always work. It is not a pleasure but a way to provide something to be considered as a 'product'. You seem to under-estimate the work it needs to design and build these 'few built-in extras': one year ago, I had quite the same features you provide in PHP_Archive/phar today. But I chose to spend several hundreds more hours on the remaining 'few built-in extras'. To resume, when I read phar's doc, I see a tool to be used by people like you or me, people with a (very) good knowledge and experience in PHP, and able to build the 'glue' scripts they need. That's what you consider 'easy', because it would be easy for you. I also find it easy, but my goal with PHK is not to provide a tool that can be used by, maybe, 100 people in the world. To resume, I consider that the features I added upon phar-like bare features are more important than you think. They are at least as important as the low-level ones. Actually, when I had to determine where to stop, I decided that, for most cases, a packager does not have to explicitely use the stream wrapper. It is now the case and the stream wrapper and every underlying features can be considered as advanced features. By contast, in phar, these low-level features are... the only ones available. > I hate to be the one to burst our bubble, but unicode is a > killer feature and PHP 6 will be adopted en masse, so if this > isn't changed, it will simply mean the death of userspace > stream wrappers for anything but custom projects. This is not the subject and it is only a personal non-specialist opinion, but I don't see many people switching to PHP 6 just for unicode support. And the main reason, IMHO, is that most don't know what it means :) Maybe in Asia, but I don't see it as a killer feature. Now, if PHP core people are silly enough to decide the death of userspace stream wrappers, OK, PHK is dead. No problem, it will have been fun anyway ! Best regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
