Re: [PHP-DEV] KINDLY GET BACK TO ME.

[Gareth Ardron]

On Tuesday 25 Feb 2003 10:55 am, wesleymougata wrote:
> MEMO
>


Just an idea, but why not have 2 lists rather than one.
One is php-dev, other is php-dev-post which ecoes content to php-dev and not 
to any of it's subscribers and make this list subscriber postings only.
Ergo, when sombody subscribes to php-dev, they're automagicakally subscribed 
to php-dev and php-dev-post and people who post using 2 or 3 email addresses 
can subscribe all their email addresses to php-dev-post without getting 3 
copies of the list.
Also, all mail to [EMAIL PROTECTED] gets checked against the subscriber 
list of php-dev-post.
At least, this is the best solution to spam I've seen in the past.

I'm not sure I explained myself that well there, but I've not have my regular 
amount of caffeine required to wake me up yet. Apologies.

-- 
Gareth Ardron
Visualcode :: 01584 861597 :: http://www.visualcode.co.uk

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

Re: [PHP-DEV] Perl-Like Pre-Destined Array Designation

[Gareth Ardron]

At 15:10 23/10/2002 +0200, Maxim Maletsky wrote:

Would be very nice to have since PHP v5. Guys?
>
> echo explode(",",$somearray)[0];
>


I would love to see it happen.


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

Re: [PHP-DEV] short_open_tag

[Gareth Ardron]

At 18:01 15/10/2002 +0200, Zeev Suraski wrote:

>I don't think you use reasonable logic in your analysis.  For instance, 
>the fact that many servers have short_open_tag turned off and for them, 
>changing the default won't pose a security risk...  So what?  That's no 
>way to look at things, really.  You have to look at those who DO have it 
>turned on (which happen to be the vast majority of installations).  You 
>could argue that there was no point changing the register_globals default, 
>since some sites have it turned off already.  Does this make sense to 
>you?  I sure hope not :)

agreed. Also, I've never seen short opening tags actively discouraged, 
which is why so many people started using them (myself included). If we 
have to alter allt he scripts from a security point of view, that's fine - 
but lets not alter it unless we have to. please.


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

RE: [PHP-DEV] bundled gd

[Gareth Ardron]

At 09:14 11/10/2002 +0200, BUSTARRET, Jean-Francois wrote:

>We are currently building apps for French iMode, and have to use a 
>closed-source non-free Windows DLL to generate our images (can't use GD 
>and imageMagick's dithering algorithm is shitty).

have a look at imlib2 and the various command line stuff revolving around 
that - far far better than imagemagick and much quicker as well


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

Re: [PHP-DEV] Re: session_register warnings

[Gareth Ardron]

At 10:40 09/10/2002 -0700, you wrote:

>I am not talking about just mine.  I am talking about a sizeable subset of
>all PHP apps that use sessions.  My problem here is that I do not
>understand the reasoning for not continuing to allow session_register to
>work on global variables regardless of the register_globals setting.  I
>do not see the benefit of changing this.

Agreed, I don't fancy spending a few days going through a shedload of 
scripts changing all the session stuff.

All it'll end up doing is annoying users no end, and what you don't want to 
do is get rid of users


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

Re: [PHP-DEV] Sugestion: Most common errors....(Session Management)

[Gareth Ardron]

At 05:36 02/10/2002 -0300, you wrote:
>Hi Gareth,
>
>I do not know about performance impacts

well, if you're talking about talking a script, "reading it-> editing it -> 
parsing -> executing", it stands to reason that this'll have more overhead 
than just "parse -> execute" and so performance will suffer.
Like I say, this is why there is the option to turn on something like what 
you're proposing in the php.ini file, but it's not enabled by default as it 
does have a performance hit.

>Lke I've said, that is just an idea for ASP guys to see the PHP Power.
>If it impacts on performance, let them know
>But this will be problem of them, just let them know that if send this
>session when it is already sent, the performance will get lower.

but this is why there is the output buffering option in the php.ini 
fileit does exactly what you're asking - it just doesn't assume that 
the programmer is an ASP guy, as most php programmers arn't.
In all seriousness, check out the output buffering option. It's there for a 
reason


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

Re: [PHP-DEV] Sugestion: Most common errors....(Session Management)

[Gareth Ardron]

At 05:06 02/10/2002 -0300, you wrote:

>Yes I know that you can't send headers to the browser when you've already
>sent some other stuffs, but ASP users have strange feeling that this is
>weird.

php.ini : Output buffering = On
what is wrong with this?

>Can't we implement some procedure that checks if Cookies and session
>commands were specified in the wrong way and automatically fix this for the
>ASP wrong programmers?

the overhead on this would be *huge*. You're talking about parsing a 
script, editing it and then re-parsing it.
The only way which this could be done without impacting on performance 
would be to enable it only when ASP style open/close tags were used, but 
even then, this'll have an effect on speed for some users.

>This procedure should minimize most common problems to bring PHP as the most
>Strong server side scripting language used in the entire internet.

I'm still failing to see what's bad/wrong about turning on output buffering.

>I am not a ASP fan, I had this problems while I was trying to bring more
>people to PHP and quit to implement Microsoft ASP solutions.

try doing image manipulation in asp, then you'll have a fairly solid reason ;)


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