Hi Stas,
On Sun, Aug 11, 2013 at 7:54 AM, Stas Malyshev wrote:
>
> > - Session fails to save if it contains special chars
>
> Session data or session variable names? If the former, it is a strange
> bug but certainly needs fixing. If it's the latter, it is the same
> exotic issue, which I suspec
Hi!
> - Session fails to save if it contains special chars
Session data or session variable names? If the former, it is a strange
bug but certainly needs fixing. If it's the latter, it is the same
exotic issue, which I suspect very small number of people actually have.
Still, I'm ok with adding
Hi Stas,
On Sat, Aug 10, 2013 at 1:53 AM, Stas Malyshev wrote:
> We can also take some responsibility for making it easier to
> upgrade
>
That's the reason why I proposed adding "php_serialize" to 5.5.
Even if there are very few users may have problem with new serializer,
it would be good to pro
Hi Stas,
On Sat, Aug 10, 2013 at 1:53 AM, Stas Malyshev wrote:
> > As I wrote, there is no real BC issue as it's just a matter of ini
> setting.
>
> There is a BC issue if you need an ini setting. You keep dismissing it
> but if it affected the app your business relates on it'd be a major
> probl
Hi!
> As I wrote, there is no real BC issue as it's just a matter of ini setting.
There is a BC issue if you need an ini setting. You keep dismissing it
but if it affected the app your business relates on it'd be a major
problem if on upgrade your app breaks and you need to scour release
notes to
> Blaming the users is simply not acceptable!
That actually depends on the organization's focus. I, for one, will gladly
blame users when they don't care when their software is deprecated. Using
deprecated software is their risk, not ours, especially when they are not
keeping in close contact wi
Yasuo Ohgaki wrote:
If users aren't reading release note of minor version up, then it is users'
fault,
not ours. If it is, we cannot release new PHP.
MANY users don't even know that their hosting has been changed until their sites
stop working ... This happens a lot more often now than it eve
Hi Lester,
On Fri, Aug 9, 2013 at 6:29 PM, Lester Caine wrote:
> Leigh wrote:
>
>> How php_serialize would cause BC issues for PHP users?
>>
>> Not everyone uses PHP in the way you would expect. Just how many sites
>> out there
>> do you think use PHPs session functionality? I'd go for hundr
Leigh wrote:
How php_serialize would cause BC issues for PHP users?
Not everyone uses PHP in the way you would expect. Just how many sites out there
do you think use PHPs session functionality? I'd go for hundreds of millions,
and that's a pretty big target to hit.
If you session_encode() s
Hi Leigh,
On Fri, Aug 9, 2013 at 5:28 PM, Leigh wrote:
> On 8 August 2013 23:31, Yasuo Ohgaki wrote:
>
>>
>> How php_serialize would cause BC issues for PHP users?
>>
>
> Not everyone uses PHP in the way you would expect. Just how many sites out
> there do you think use PHPs session functionali
On 8 August 2013 23:31, Yasuo Ohgaki wrote:
>
> How php_serialize would cause BC issues for PHP users?
>
Not everyone uses PHP in the way you would expect. Just how many sites out
there do you think use PHPs session functionality? I'd go for hundreds of
millions, and that's a pretty big target t
Hi,
On Thu, Aug 8, 2013 at 9:10 PM, Lester Caine wrote:
> Leigh wrote:
>>
>> I can't judge the scope of the break, or how many users will be affected.
>> I
>> just want to say that breaks without a good reason shouldn't happen.
>>
>
> Seconded.
>
> In hindsight I personally would have preferred
Leigh wrote:
On 8 August 2013 12:05, Yasuo Ohgaki wrote:
>What's the point of having old serialzers that is bonded to
>"register_globals"?
>This kind of change should have done when 5.4.0 was released, IMO.
>
Because somebodies code will depend on functionality not changing, and we
shouldn't
On 8 August 2013 12:05, Yasuo Ohgaki wrote:
> What's the point of having old serialzers that is bonded to
> "register_globals"?
> This kind of change should have done when 5.4.0 was released, IMO.
>
Because somebodies code will depend on functionality not changing, and we
shouldn't break their c
Hi Leigh,
On Thu, Aug 8, 2013 at 7:53 PM, Leigh wrote:
> but I'm not sure if it should be default behaviour.
What's the point of having old serialzers that is bonded to
"register_globals"?
This kind of change should have done when 5.4.0 was released, IMO.
Regards,
--
Yasuo Ohgaki
yohg...@ohg
Sorry I failed at reply to all.
On 8 August 2013 11:38, Yasuo Ohgaki wrote:
> Hi Leigh,
>
> On Thu, Aug 8, 2013 at 7:23 PM, Leigh wrote:
>
>> Are you keeping it as optional for 5.6 and not the default? If you're
>> making it default don't we need to vote on BC breaks?
>
>
> I suppose affected u
Hi Lester,
On Thu, Aug 8, 2013 at 5:26 PM, Lester Caine wrote:
> We need to help get the rest of the infrastructure working with PHP5.4
> before starting work on 5.6 ... let alone 5.5 ...
Since 5.5 is just released, some fixes may be good to add.
However, I agree that released version is bette
Yasuo Ohgaki wrote:
Or make it optional for 5.5 and 5.6, write full documentation about
serializer
and make new serializer default for future releases.
It would work better. There would be enough time for users may have BC
issue. If they do, it would be simple task to adopt because it is plain
s
Hi Stas,
On Thu, Aug 8, 2013 at 11:11 AM, Yasuo Ohgaki wrote:
> On Thu, Aug 8, 2013 at 11:03 AM, Stas Malyshev wrote:
>
>> > Removing unneeded limitations, rather than forcing them to users, is
>> user
>> > friendly and the way to go. IMHO.
>>
>> If we wrote it from scratch, sure. But if we alre
Hi Stas,
On Thu, Aug 8, 2013 at 11:03 AM, Stas Malyshev wrote:
> > Removing unneeded limitations, rather than forcing them to users, is user
> > friendly and the way to go. IMHO.
>
> If we wrote it from scratch, sure. But if we already have existing and
> working one, having people to deal with m
Hi!
> Removing unneeded limitations, rather than forcing them to users, is user
> friendly and the way to go. IMHO.
If we wrote it from scratch, sure. But if we already have existing and
working one, having people to deal with migrating data and
incompatibilities that arise IMHO is not worth the
Hi Stas
On Thu, Aug 8, 2013 at 10:03 AM, Stas Malyshev wrote:
> > Personally, I would not use numeric index.
> > However, users are expecting it to work and there is no way to raise
>
> I don't think it is reasonable to expect it to work, it never worked, it
> never was documented to work and the
Hi!
> Personally, I would not use numeric index.
> However, users are expecting it to work and there is no way to raise
I don't think it is reasonable to expect it to work, it never worked, it
never was documented to work and there's no real use case for it.
> The limitation is come from regist
Hi Stas,
On Thu, Aug 8, 2013 at 5:34 AM, Stas Malyshev wrote:
> Why is it useful to do this? I don't see how using numerical indexes in
> global namespace (and SESSION is one of global namespaces in PHP) is a
> good idea. Could you explain the use case here?
>
Personally, I would not use numeric
Hi!
> Current session module has a few limitations due to "register_globals"
> support which is now obsolete. One of them is numeric key indexed session
> data. i.e. $_SESSION[1] = $var is not allowed now and it raises error at
> R_SHUTDOWN with useless message for debugging.
Why is it useful to
Hi all,
Current session module has a few limitations due to "register_globals"
support which is now obsolete. One of them is numeric key indexed session
data. i.e. $_SESSION[1] = $var is not allowed now and it raises error at
R_SHUTDOWN with useless message for debugging.
https://bugs.php.net/bug
26 matches
Mail list logo
