Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68469
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52051E71.9010309@sugarcrm.com>
References: <CAGa2bXbn_U9GBnskNwdJqDzFpBXeucT-Q7SoQ3hmQ59u-6=KDw@mail.gmail.com>
 <5202FC8A.2070307@sugarcrm.com> <CAGa2bXYdwZLfadyNm+mUpw9mHmQS9Ybh013hs73CMW=e-UnwxA@mail.gmail.com>
 <CAGa2bXbUD7sDAteUFncw6gYVjN4etw1fPT0eDK3CAXrEzc-oWA@mail.gmail.com>
 <52035622.1090301@lsces.co.uk> <CAGa2bXaHyONvikGLvuNLxPJ9nrtqs=HxXcFJJg5_raC5tyF70A@mail.gmail.com>
 <CAPwsocHeQxiwhCE5=4S5ii9vZy8KmU9XCLRrRgA0MnZf0G67vQ@mail.gmail.com>
 <CAGa2bXY9+raaFikqpbWFwgUvOxeQr7naPXR92s9HXsRiPXdmbw@mail.gmail.com>
 <CAPwsocFL=pBc_KEZ3hFjTjpaXxF5HHGzy8V8_WUYa8+SpX0oKw@mail.gmail.com>
 <CAGa2bXbywtEyPmE-G4TDk-ofWAXpK-sL18AanJ40Bmq-9vAokg@mail.gmail.com>
 <CAPwsocGf6L2a1+iQq6-HXTAwE5Gv_HtFnUS8_6s-1XA3nin5Fw@mail.gmail.com>
 <52038ABF.8060904@lsces.co.uk> <CAGa2bXabMOJUR6_PO-AgEQ4SKSnG5F-gQrOFeF7U=66LyuYn=w@mail.gmail.com>
 <CAPwsocEesVo23dFrut0gT8p=Bp8SraEAZAD61qKUPW6FGZ783A@mail.gmail.com>
 <5204B690.4060006@lsces.co.uk> <CAGa2bXbLFzDkW834gTM=G8rDXOk47Z_AO1B6eRpNT_vRMWq5CA@mail.gmail.com>
 <52051E71.9010309@sugarcrm.com>
Date: Sat, 10 Aug 2013 06:14:26 +0900
Message-ID: <CAGa2bXY8CnhJot8w7JWVM2JGpoWfJH2Y7qTQcx4UXj4AfxPLKg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Lester Caine <lester@lsces.co.uk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133dba0cfb99e04e38a44e4
Subject: Re: [PHP-DEV] "php_serialize" session serialize handler
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1133dba0cfb99e04e38a44e4
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Sat, Aug 10, 2013 at 1:53 AM, Stas Malyshev <smalyshev@sugarcrm.com>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
> problem if on upgrade your app breaks and you need to scour release
> notes to figure out all settings you need to change for each upgrade. So
> we try to minimize such cases.
> In some instances, it's unavoidable - but in this case, the support for
> numerics in _SESSION is an exotic feature that will be of little use for
> 99% of PHP users. So introducing additional upgrade headaches for this
> is IMHO unnecessary.


I think we are not talking about newbie users. Users who share session data
among web servers are advanced users and they would not have problem
reading release notes before upgrading.

Most of users don't have care at all. If there is old session data, it's
just discarded.

 > I'm not going to remove old one, though. Search bug db, there are many
> > bug reports/feature requests that this patch solves.
>
> How many bug reports are there requesting numeric index support in session?


It's one type of bug report that relates to this patch. There types
bug/requests.
Most of them are old one I suppose. IIRC, there were

 - Session fails to save if it contains special chars
 - Want unserialize session from session data, not from $_SESSION
 - Need function generates initial session data via dession_decode
 - Session should use plain serialize

These are occasionally pops up and closed as "not a bug"/"wont fix". I
remember
since I was one of them closed as "not a bug"/"wont fix".


> > 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.
>
> We can. We can also take some responsibility for making it easier to
> upgrade and not just say "we had it all in the fine print, it's your own
> fault for not reading everything". Vendors that do that are usually
> disliked by their customers.


Even if there are users do not reading release notes, it does not break apps
as it creates new session data.

Users don't have clue, they would not have problem.
Users may have affected, they should be able to read release notes.
There wouldn't be upgrade headache.

We don't want to keep misdesigned component due to "register_globals",
don't we? Especially when the solution does not have real BC issue.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1133dba0cfb99e04e38a44e4--