Jyri / Team Please find the updated version here which incorporates review comments - http://wikis.sun.com/download/attachments/10390064/php-5211-arc-draft-v1.txt
- Sriram Sriram Natarajan wrote: > > > 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 > _______________________________________________ > > > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
