[phpa] Re: About registration and Re: Re: PHPA 1.2 Released

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


Other related posts: