Wow, what a stir! I guess that you can easily spend as much time building sophisticated code to make the registration process smooth, as you did writing the product..! Some other suggestions would be that there are almost certainly as many beginners (like myself) out there who have trouble locating their php.ini with both hands as their are with sophisticated 500 domain setups. =20 Since a large majority of us will be running internet facing webservers, or at least with internet access, then perhaps you could also consider either adding a setup routine, or a php config page which helps locate the correct files and grab the reg keys automatically. Taking this to its conclusion you could perhaps have a flag to indicate that it is OK to do auto registration at run time, ie for those with dynamic virtual hosts, then on first use PHP spots that there is no reg key and fetches one. Obviously this should be an option so that it can be disabled by the paranoid. I think that it is certainly true about voluntary registration. To be honest I run a little home page mainly for the fun of it, and the 2 other people in my family who look at it twice a year... So I certainly would consider it worthy enough to add in your list of "sites making *use* of phpa". However, it has made my 400Mhz machine useful, instead of being too slow(!), and I am sure that there are many people like myself, who when added together make a useful sized universe. If you would like to be able to measure that universe, then that is fine by me! HOWEVER, the only request that I would make is that if you are ultimately interested in charging (which is fine by me, good to see someone making some money out of their hard work!). Then please consider some of these tiered systems based on usage, eg my company can afford a lot more than I am willing to pay. For example the cheap/free for personal usage versus paying for commercial usage seems attractive - to me because I am in the personal bracket :-) - but I have no experience as to whether that gets abused in practice... Either way - good luck! Great product - hope you are still motivated to keep up development! Ed Wildgoose -----Original Message----- From: Nick Lindridge [mailto:nick@xxxxxxxxxxxxxxxxxxxxx] Sent: 22 January 2002 19:23 To: phpa@xxxxxxxxxxxxx Subject: [phpa] Re: About registration and Re: Re: PHPA 1.2 Released Sigh. Ok, so I knew that this might cause a stir. Firstly to address what I can remember from Montes next email. As I said earlier, there's no sinister or ulterior motive behind the registration idea. It's simply to answer some questions of my own about it's use or non-use. Having written something fairly substantial that should be useful to some people, I think that it's not unnatural to be curious about who is hopefully getting the benefit of it. Even though there's no formal support contract or anything of the kind, I'd still like to know who my 'customers' are and who I'm in part responsible for helping to be on the web. About a volunteer registration, my experience suggests that people simply wouldn't bother. When I last asked if people were actually using it I had two responses. Maybe that really was an accurate response a couple of months or so ago. Maybe it still is. I just don't know. Working on projects such as this can take a large chunk of time, and if people really aren't using it then I'd simply stop. Even the first version, bugs and all, was working for a site that I was working on at the time, and the only reason I wrote it was initially to accelerate that work, although in the end I stopped working on the site and decided to direct efforts into making phpa better. > This key-per-virtual-hostname scheme may have just thrown an > (unneccesary) wrench into the gears, so to speak. This sounds like it > could be quite a hassle for mass volume virtual hosts or cluster-based > hosting, and for what exactly? If it isn't feasible to manually edit a virtual hosts file, perhaps because it gets rebuilt frequently rather than being edited, then you're probably correct and the keys feature is unacceptable. > Imagine if you had to register each host > to use PHP itself... it would be quite unpopular. Why? You have to set other things. Even if a hosting company uses tools to build config files entirely, e.g. from information in a database, if the tools are any good then shouldn't it be possible to add arbitrary 'features' to the virtual hosts section, including adding directives such as php_value? If it's a pain then I really believe that the fault is in the tools used for managing the web server config files, not in the requirement to add a particular directive, which in itself isn't that unreasonable. But I realise that changing the key feature or using APC instead might be easier than fixing lame site management software. > What about things > like privacy issues. Why can't I use it on an undisclosed website, or > maybe its on a private network that I don't want to disclose > information about? Disclosing an IP such as 192.168.1.3 to me doesn't tell me anything about your network other than it's private. I have a 192.168.1.3 for one of my machines at home, and so do many thousands of other people. If you use an internal domain name then yes you'd be disclosing that, but I'm not about to start hacking or building a black book of hidden sites that I know of.=20 Furthermore I'm certainly not going to disclose the information to anyone else. You implicitly trust me by taking pre-built code and installing it on your machine, and that btw. gets to run as root because it's first called before Apache switches user/group id's. I'm not about to then break that trust by exploiting personal information that you give me in any way. > Just bringing up some possible issues here, in case you are planning on > making this a permenant "feature" of phpa. I was really looking forward > to a nice drop-in solution to php acceleration, and this just killed > that idea. A drop in solution *is* the idea, and even with the key, for many sites it will still be just that. Getting a key and adding it to a web server config file should be a trivial task. But I do realise the possible problems as mentioned above for companies supporting many sites, although I'm sure that there are other such companies where that wouldn't be a problem. =20 > If you _have_ to have a license to use the product, I'd vote for an IP > based or host-id based license, in that order. I thought about this idea too but there are downsides, and it also wouldn't accurately reflect or capture its usage. I've also considered having phpa=20 connect to a remote server to announce that it's serving a particular domain, but I suspected that this wouldn't be popular. But what do you think? Would you mind if it was doing this? Nick ------------------------------------------------------------------------ www.php-accelerator.co.uk Home of the free PHP Accelerator To post, send email to phpa@xxxxxxxxxxxxx To unsubscribe, email phpa-request@xxxxxxxxxxxxx with subject unsubscribe ------------------------------------------------------------------------ www.php-accelerator.co.uk Home of the free PHP Accelerator To post, send email to phpa@xxxxxxxxxxxxx To unsubscribe, email phpa-request@xxxxxxxxxxxxx with subject unsubscribe