[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. 
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.  

> 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 
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

Other related posts: