Re: [PHP-DEV] RfC: version names

[Sander Steffann]

Hi,

> > So what happens if I do this?
> > 
> >   cd php4
> >   cvs upd
> > 
> > and a day later do this?
> > 
> >   cd php4/ext/standard
> >   cvs upd
> > 
> > What is the checkout date here?
> 
> I've no idea, do you? I think we just should not allow submissions with 
> test results if they're not made by a snapshot or our phport.sh thingy 
> for automatic testing.

Sounds a lot more reliable :)
Sander



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] auto_prepend/append: does the PHP engine cache the

[Sander Steffann]

Hi,

> > What about setting server variables? You can set them once, they stay in
> > memory and your scripts can read them. Just an idea...
>
> Hum ... very interesting! I have no idea how to set Apache server vars
> but I'll definitely look into it!

We do the following in our Apache virtual hosts:


ServerName  www.example.com

DocumentRoot/var/www/www.example.com/

SetEnv  cityapeldoorn
SetEnv  region_id   97
SetEnv  module_name index


You can then access these from PHP:



Good luck,
Sander.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Forked ext/gd by default

[Sander Steffann]

Hi,

> I think we should use forked version of gd library by default for 4.3.0.
> From what I hear it is already the best version of any of them out there
> and if it saves us any more grief, all the better. Objections?

Sounds wonderful!
+1 from me.

Sander.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases

[Sander Steffann]

Hi,

> To php-dev: I feel that Robert has had a bit of a cool reception;
> opensource development relies on positive feedback to make progress.

Sorry that I'm late :)

I too think this is a very nice extension!!! We (nederland.net, hosting
provider in The Netherlands) don't need this yet, but I expect that in the
future we will have customers asking for something like this... I expect
this extension will be very valueable for a lot of PHP users.

Keep up the good work!
Sander


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.3.0 released

[Sander Steffann]

Hi All,

There is a weird line in here too:

>  * PHP Manual: Using PHP from the command line
>http://www.php.net/manual/en/features.commandline.php

It's this one:
By default when executing make, both the CGI and CLI are built and placed as
sapi/cgi/php and sapi/cgi/php respectfully

The second path is wrong, and respectfully should be respectively.

But I'm glad the CLI is 'official' now! :)
Sander.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] safe_mode redesign

[Sander Steffann]

Hi Jason,

I also have some ideas how to improve safe_mode:

- Being able to limit the hosts/ports the socket/mysql/fopen/etc functions
can connect to. I have seen a few cases where a PHP user used the socket
calls to send spam to a mailserver. He/she deleted the script afterwards,
and nobody was able to find out who sent the spam...

- Extend the functionality of open_basedir. This could be used for the
virtual-chroot / shared directories you mentioned.

- I can imagine that the configuration files can become very large when you
want different limits for different groups of users. So maybe a way to make
'shortcuts' for certain settings? For example something like:

php_admin_varbasic_dirs/var/www/shared:...:...:...
php_admin_vardb_users  /var/www/db:/usr/local/php/:...:...
php_admin_varpower_users   $db_users:/var/www/power:...


php_admin_value  open_basedir  $basic_dirs



php_admin_value  open_basedir  $basic_dirs:$db_users



php_admin_value  open_basedir  $basic_dirs:$power_users


This could make managing a lot of virtual hosts very easy.

Just some ideas. I don't know yet how many time I can set aside to help on
implementing security features...
Sander.

- Original Message -
From: "Jason Greene" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, February 01, 2001 9:53 PM
Subject: [PHP-DEV] safe_mode redesign


> Is anyone up for a discussion on the redesign of safe_mode? I would like
to start working on this sometime soon, and I have a lot of
> ideas, but I know this is going to be something of a large debate.
>
> Some of the  new features I think would benefit php include:
>
> * safe_mode_hide_env_vars - will allow extra protection on removing
environmental vars from hosted users ( I actually have a patch
> for this but  I have been waiting on it to discuss the redesign)
>
> * User configurable policy - safe_mode could have configuration directives
to specify exactly what checks are desired
>
> * Virtual Chroot - the ability to perform a chroot to a virtual host
directory structure, so that a hosted user can not access
> anything outside of their directory structure.
>
> * Shared Directories - The ability to specify a list of paths that are
shared amongst all hosted users. This would allow certain
> extensions (gd, oracle, etc) the ability to access the needed datafiles
without failing a safe_mode check.
>
> Any comments, suggestions, other ideas?
>
> -Jason
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: safe_mode redesign

[Sander Steffann]

Hi Zeev,

>-- Quoted from Zeev:
> The one main problem with safe_mode in general is that the idea is
> problematic by definition.  Security outside the OS level is prone to
> errors, and a false sense of security is much worse than knowing you're
> insecure.

I agree. I think this means that either:
- We shouldn't do very much on security
- We should make clear we are NOT providing complete security, but that we
only try to help the administrator by giving him some extra options.

> In my opinion, safe mode should only feature features which can have an
> infrastructure-level solution, and are not prone to errors.  There aren't
> too many of these.  The current safe mode implementation is extremely
prone
> to errors because it tries to protect opened files, and the way its built,
> it's bound to be missing checks in many places...

I know :(

Maybe we could make a document that describes what a module/extension should
do to be considered 'safe-mode compatible'. That way it would be easier for
the module author to check his code. I don't believe anyone is intentionaly
writing 'insecure' code.

Sander.



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 5

[Sander Steffann]

Hi,

> > Always building the CGI version would also help the PEAR command
> > line installer a lot since it currently needs a PHP binary to be
> > executed.
>
> Yes, I had that in mind. We should get /usr/bin/php on as many machines as
> possible.
> This message from Stig S. Bakken summarises nicely what I'm trying to say:
>
> http://marc.theaimsgroup.com/?l=php-dev&m=100313140811956&w=2

Sounds very useful. I'm using PHP more and more instead of shellscripts,
mostly because I am more familiar with it.

+1 from me
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Sander Steffann]

Hi,

We do exactly the same with Apache SetEnv:

SetEnv  media_regionaamapeldoorn
SetEnv  media_regioid  27
SetEnv  media_module   index

And we get them in the PHP script with
$GLOBALS['HTTP_SERVER_VARS']['media_regionaam'];

Works great for us.
Sander

- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Joe Webster" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 11:40 PM
Subject: Re: [PHP-DEV] Re: PHP 5


> This could probably be done.  It does sound helpful.
>
> Zeev
>
> At 00:29 03/01/2002, Joe Webster wrote:
> >Yes it would have to be in every script in the vhost, location or
directory
> >directive.
> >
> >It could be a constant =) That would make my life easier.
> >
> >Thanks,
> >-Joe
> >
> >"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> >5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > > At 23:33 02/01/2002, Joe Webster wrote:
> > > >I have something that I am currently dealing with:
> > > >
> > > > Using mod_perl with apache, you can put this in a apache
directive
> > > >(vhost, location, directory):
> > > > PerlSetVar somevarname somevarval
> > > > and that would pre-define somevarname equal to somevarval. We
are
> >trying
> > > >to move completely to php (we're 1/2 php and 1/2 perl) however, we
really
> > > >need to be able to set the vars like this. I did look through the
> >mod_php.c
> > > >and I noticed the php_value, php_flag, php_admin_value, and
> >php_admin_flag,
> > > >but nothing for a variable.
> > >
> > > Would it be defined in every PHP script that runs?  Does it really
have to
> > > be a variable, or can it be a constant?
> > >
> > > Zeev
> > >
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] FOSDEM 2002

[Sander Steffann]

Hi,

> Sterling and I will have a session there, it's just not updated on the
> site I guess.

Any idea when your session will be?
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]

[Sander Steffann]

Hi,

IMHO making PHP case sensitive after being case-INsensitive for so many
years is a very bad idea. The reasons are already mentioned on the list. For
us (ISP in The Netherlands) the most important one is BC. We would not be
able to upgrade any of our servers when this would go into PHP5. A lot of
our customers use PHP, and I think almost every customer would have scripts
that break. (which is not acceptable ofcouse)

Please don't do this... (That's a -1 from me)
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]

[Sander Steffann]

Hi,

> Even with the whole new object API, most of the code would work without
> modifications (at least mostly all of the PHP object code I got to take a
> look at).  And if it doesn't - turning on PHP 4 compatibility should
bridge
> the gap...

Glad to hear that :)

I have been thinking, and breaking BC _could_ be acceptable for us, but only
if it is possible to run PHP4 and PHP5 side-by-side in one apache server...

(Breaking BC with making everything case sensitive would introduce a nice
possibility to clean up a lot of other things that were never doen to
maintain BC though, but lets stick to this point for now :)

Sander.




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Nostalgia

[Sander Steffann]

Please stop discussing people, and start discussing PHP. Be mature enough to
let this rest. This discussion will lead nowhere.

Thanks ;)
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Links to companies supporting / teaching PHP

[Sander Steffann]

Hi,

To keep it short and simple: A related company is teaching PHP courses. Is
there a place where things like this could be mentioned on the php.net site?

Thanks,
Sander Steffann
Computel Standby BV / www.nederland.net / php.nederland.net



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs: ext/baby

[Sander Steffann]

Hi Rasmus/Christine,

> @@ -1,2 +1,6 @@
>  Christine Lerdorf
>  Rasmus Lerdorf
> +Buster (working name only) Lerdorf
> +Born 13:26 PDT Wednesday March 6, 2002
> +Weight: 9.0 pounds
> +Length: 19.25 inches

Congratulations!
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's fork GD!

[Sander Steffann]

Hi,

> Well, as far as I understand it, simply reading an LZW compressed GIF
> would not violate the license.  It is software that creates LZW-compressed
> GIF files that need to pay up.  So, we could still support GIF and
> manipulate LZW-compressed files, but once we read it in and manipulate it,
> we would not be able to write out an LZW-compressed GIF.  That means the
> GIF files created by PHP-GD would be much larger.

Which is not a problem IMHO. Like said before, GIF should go away. The only
reason to support GIF (for me at least) is to make it possible to migrate to
other formats gradually, without breaking existing scripts. We still have
users who use GIF output, and it would be nicer to say to them: migrate to
PNG because it is more efficient, than: migrate to PNG *NOW* otherwise your
site won't work anymore...

Oh, yes, and a +1 from me on integrating GD!
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV]

[Sander Steffann]

Hi,

> From: http://www.w3.org/TR/2000/REC-xml-20001006#sec-pi
>
> [16]  PI   ::='' Char*)))? '?>'
> [17]  PITarget ::=Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
>
>  [3]  S::=(#x20 | #x9 | #xD | #xA)+
>  [2]  Char ::=#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x1-#x10]
>
> Meaning that between  everytning is allowed but '?>'.

Nice to know! Not that it matters to the http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP's vision

[Sander Steffann]

Hi,

> > And doesn't ZE2 address almost all of those OO related things?
>
>   It does. Personally, I'm missing two things in Zend Engine 2.0:
>   interfaces and private methods. Both are not really critical, as they
>   don't aim at solving technical problems, but social ones during the
>   design process.

Private methods would be very nice to have. Like you said, technically it
doesn't matter, but it makes it easier to 'educate' people.

Example: I have written some classes for my company, and I made docs that
explained all the available methods. Now a co-worker had a look at the
sources, and decided that a few 'internal/undocumented' functions were
useful to him... Since I didn't know those functions were used outside the
class, I changed them and broke some of his code.

The obvious sollution would be to educate my co-worker about using
undocumented features, but doing this through programming language
constructs makes this a lot easier (and I can be SURE nobody uses that code
where they shouldn't).

Just my personal reasons why I would like private methods :)
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] oo != php

[Sander Steffann]

> OO IS OO... JUST BECAUSE JAVA IS OO DOESN'T MEAN WE ARE SUGGESTING MAKING
JAVA
> AGAIN. WE ARE SUGGESTING MORE OO FEATURES. Please Pleas Please realize the
> difference. Im sick of people associating oo features as java features!
>
> Making php more like java would be suggesting making a public static void
> main(String args[]) in a class, and that gets run when a class with that
name
> is loaded. Now this is stuff specfic to java! Not MI or public/private
members
> these features have been around way before java was ever thought of!!!

I completely agree here. Having some extra OO features would be nice.

There are a few conditions:
- Using them must be optional
- Performance should not suffer too much
- A clean implementation is possible

If adding a few OO features for the people who want (or even need) them can
be done under these conditions, I think it should be considered seriously...
If one of these conditions can not be met for a certain feature, it won't be
worth adding IMHO.

Sander.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Error in zend2_example.phps

[Sander Steffann]

I think zend2_example.phps has a little error in example 6:

The display function is defined as:
function display()
{
print $this->name;
print "\n";
}

But then it is called with:
print $person->getName()->display();

Either the function should use return, or the call shouldn't use print...




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CLI SAPI (was Re: [PHP-DEV] 4.3 release call to arms)

[Sander Steffann]

> I think the only remaining issue here is to be able to have a separate 
> config/ini file for cli.  While we're at it we might as well support 
> SAPI-specific config files, so PHP first looks for php-$SAPI.ini, then 
> php.ini.

Sounds like a good idea.
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Sander Steffann]

Hi,

> >Deprecate dl()? I think it's one of the most useful functions... :)
>
> How so?  I can understand that people get used to it, but it's really
> bad.  extensions should be loaded in the php.ini file.  There's really no
> good reason for using dl() over the php.ini method.

I agree with you when we are talking about using PHP in a webserver.
However, I am seeing more and more use of PHP as a generic scripting
language. In this situation, I think dl() is very useful...

Imagine a application written in PHP that has a 'special' extension. For
example, an extension to access a scanner. You don't want this loaded
everywhere, just in your scanner application, and certainly not in your
webserver.

In a few words:
For a webserver: ban dl()
For generic scripting: keep dl()

Sander.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Versioning (resent AGAIN due to lack of replies)

[Sander Steffann]

Hi,

> PHP_VERSION_NUM

+1 from me too.

> Example:
> GD_EXT_VERSION = 30201

Very big +1 on this one (or something similar). What also would be useful is
a built-in way to determine optional parts of extensions, like something to
check if GD supports GIF/PNG/etc. This way, you can check the version and
the optional parts.

Sander.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Versioning (resent AGAIN due to lack of replies)

[Sander Steffann]

Hi,

> >Very big +1 on this one (or something similar). What also would be useful
is
> >a built-in way to determine optional parts of extensions, like something
to
> >check if GD supports GIF/PNG/etc. This way, you can check the version and
> >the optional parts.
>
> You mean this:
> http://www.php.net/manual/en/function.imagetypes.php

Yes, but in a generic way, so other extensions use it too.

Sander.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

[Sander Steffann]

> > I think the key still lies in creating a repository for C extensions
where
> > each extension can have its own release cycle.
>
> +1 one for this... :-)

Sounds good. I think this would make it easier for the developers of the
extensions AND the developers of the 'main' code. The drawback is that it
could make it more difficult for someone to determine what he needs to run a
certain script. But at the moment, a lot of people compile their own PHP
with the extensions they need, so the problem already exists. When using a
central repository it should work fine (I think ;)

So that's a +1 from me too.

Sander.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: exit() / die()

[Sander Steffann]

> I'm glad I read the list.  Doing (a) will break several scripts that my
site
> depends on.

Ok, I was mistaken in thinking it wouldn't break (a lot of) existing code.

> "Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> news:5.1.0.14.2.20010929020430.051aa2a8@localhost...
> > Guys,
> >
> > Changing these is quite out of the question - they've been a core part
of
> > the language since 1997 (at least), and have lots of lines of code that
> > rely on them.  Moreover, there's no clear-cut reason to change it,
> > especially considering it only makes sense when used in command-line
mode,
> > whereas the current behavior is useful in all SAPIs (in order to
introduce
> > such a compatibility-breaking change, we need a *good* reason).

You are right. I have been doing some command-line work lately, and I was
surprised that exit() didn't do what I expected. But PHP is still (mostly) a
web-server language, and there it would make no sense indeed.

Changing my vote to -1 on changing and +1 on introducing a new function :)
Sander.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]