Sriram Natarajan wrote:
> In a separate post , I mentioned the overall idea of splitting PHP
> optional extensions into its own packages to allow simplified
> install. Accordingly, I have included this feature in this below ARC
> draft. please let me know, if I missed some thing.
>
> http://wikis.sun.com/download/attachments/10390064/php-5211-arc-draft-v1.txt
>
> Update to PHP 5.2 to deliver additional PHP features within OpenSolaris.
>
> 09 September 2009
I believe I'm reviewing the latest version, although it is dated from
9/9. Is this still the latest?
> c) Introduce new PHP DTrace probes and update existing PHP DTrace probe na
> 'exception-catched' is now changed to 'exception-caught'. This change
> is done to keep DTrace probe names consistent with upstream community.
To confirm, the only customer-visible impact is having to rename
'exception-catched' to 'exception-caught' in all dtrace scripts
customers have written so far?
> We propose to package apc, memcache, suhosin, tcpwrap, xdebug, idn
> as separate extensions as well. This is being done to allow
> running these extensions out of the box. Currently, users will
> need to manually enable these extensions by editing the
> corresponding ini file.
Elaborate a bit more on what each package does. I'm assuming each
package delivers
/usr/php/5.2/modules/foo.so and
/etc/php/5.2/conf.d/foo.ini
such that installing the package automatically enables that extension
(after the next restart of PHP).
True?
Any exceptions to that behavior pattern?
> We propose to drop bundling 'dtrace.so' within SUNWphp52u
> package. This extension has been rolled into PHP engine itself.
> So, there should be no loss of functionality with this change.
Do users have to care about this detail? As long as customer's
existing dtrace scripts continue to work as-is (modulo the one rename
noted above), is there a customer impact on whether the implementation
lives in dtrace.so vs. baked into the main binary?
> 3.1 Interface Stability.
>
>PHP, as an Open Source project, is controlled by a group of developers
>external of, and independent from, SMI. The PHP Group makes no guarantees
>or promises of ABI or API compatibility between PHP releases.
Not relevant. Here you're documenting what stability the OpenSolaris
maintainer of PHP (you) is delivering to OpenSolaris customers.
> 3.2 Imported Interfaces.
>
> NAME STABILITY NOTES
>
> NCurses Volatile PSARC/2008/203
2008/203 is libmcrypt not ncurses
> unixODBC Volatile LSARC/2007/684
2007/684 proposal didn't list interface stabilities, but reading
through the mail log it later mentions the APIs are Uncommitted and
the tools are Volatile. I assume the PHP extension is importing the
APIs, so the above appears to be incorrect.
> 3.3 Exported Interfaces.
>
> 3.3.2 PHP DTrace probe names
>
> NAME STABILITY NOTES
>
> request-startup Volatile
> request-shutdown Volatile
> compile-file-entry Volatile
> compile-file-return Volatile
> execute-entry Volatile
> execute-return Volatile
> execute-file-entry Volatile
> execute-file-return Volatile
> exception-thrown Volatile
> exception-caught Volatile
> object-create Volatile
> object-free Volatile
> gc-begin Volatile
> gc-end Volatile
So to confirm, these are all new probes being introduced now?
Where are they documented? e.g parameters available?
You also need to list the removed one
exception-catched Removed (replaced by exception-caught)
> SUNWphp52u Uncommitted
Package Name
> SUNWphp52r Uncommitted
Package Name
These exist already, they are not being introduced by this case. Don't
list interfaces which haven't changed since the last case.
> SUNWphp52u-apc Volatile
> Package N
ame
> SUNWphp52r-apc Volatile
> Package N
ame
> SUNWphp52u-suhosin Volatile
> Packag
e Name
> SUNWphp52r-suhosin Volatile
> Packag
e Name
> SUNWphp52u-xdebug Volatile
> Package
Name
> SUNWphp52r-xdebug Volatile
> Package
Name
> SUNWphp52u-idn Volatile
> Package N
ame
> SUNWphp52r-idn Volatile
> Package N
ame
> SUNWphp52u-tcpwrap Volatile
> Packag
e Name
> SUNWphp52r-tcpwrap Volatile
> Packag
e Name
> SUNWphp52u-snmp Volatile
> Package
Name
> SUNWphp52r-snmp Volatile
> Package
Name
> SUNWphp52u-memcache Volatile
> Packa
ge Name
> SUNWphp52r-memcache Volatile
> Packa
ge Name
You'll want to proactively explain in the case why Volatile. Do you
expect to need to refactor these again in 5.2 lifetime?
> /usr/php/5.2/modules/*.so Volatile
Why do these need to be public interfaces? Do customers need to link
against them directly?
--
Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
