Jyri Virkki wrote: > 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? > > thanks for looking into this. This is the latest revision. The date reflect the original date when I posted the very initial revision. > >> 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? > yes. > > >> 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? > > > That is the expected behavior. No other exceptions to this (at this point.) >> 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? > > It should not matter to customers. They should not know where the probes are coming from. > >> 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. > Ok. > >> 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) > > > not everything is new. the following are new
object-create Volatile object-free Volatile gc-begin Volatile gc-end Volatile I listed every one of them (because I could not find the stability level of the previous one. So, I listed all of them for clarity sake) >> 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. > > Ok > > >> 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? > > > These 3rd party extensions may not life for a long life unlike the case with regular PHP distribution. These are bundled for convenience sake. Hence, I am hoping to catch them with Volatile. >> /usr/php/5.2/modules/*.so Volatile >> > > Why do these need to be public interfaces? Do customers need to link > against them directly? > > > Makes sense. I will provide the updated version
