1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
Component: Zend Engine 2
Important stuff to finish: PPP members/PPP methods,
support of overloaded extensions, possibly differentiate
between class and namespace as discussed with Stig in
Germany.
Responsibility: Zeev, Andi, Stas
Time frame: Couple of months for first part and extensions will be
ongoing while PHP is being fixed.
Things to leave for later versions: Native aggregation
support, accessing static members via object and not class.
Component: Aggregation
Responsibility: Andi, Stig?
Time frame: ?
Component: Introspection
get_function_definition(<is_callable> [field]) =>
array(
file => filename
line_start =>
line_end =>
parameters => array( name, byref, default )
static_variables => array( name, value/default )
scope => 'namespace' | 'class' | null
namespace => classname | namespacename | 'main'
protection => protection_flags
phpdoc => pre-scanned-phpdoc-string
type => 'internal' | 'user'
)
get_class_definition(<class> [field]) =>
array(
type => 'internal' | 'user'
file => filename
line_start =>
line_end =>
name => pretty-name
parent => classname | namespace | null
flags => bitfield (ABSTRACT)
methods => array( array( name, phpdoc ) )
default_properties => array( array( name, value, phpdoc ) )
private_properties => array( array( name, value, phpdoc ) )
protected_properties => array( array( name, value, phpdoc ) )
public_properties => array( array( name, value, phpdoc ) )
static_members => array( array( name, value, phpdoc ) )
constants => array( array( name, value, phpdoc ) )
classes => array( array( name, phpdoc ) )
phpdoc => pre-scanned-phpdoc-string
)
get_constant_definition(<constant> [field]) =>
array(
file => filename
line_start =>
line_end =>
name =>
value =>
phpdoc =>
)
get_global_variable_defintion(<name> [field]) =>
array(
file =>
line_start =>
line_end =>
name =>
phpdoc =>
)
We tried to take into account the implementation of each piece of
information, and there are some that are problematic, especially those
regarding constants and global variables (where do we store the extra
information?)
With "pre-scanned-phpdoc-string" we mean converting:
/**
* Blah blah blah
* @param foo ...
*/
to:
Blah blah blah
@param foo
The rest of the phpdoc handling should be left to an extension.
Responsibility: Stig, Andrei, Harald
Time frame: ?
Component: Redesign of API Versioning
Responsibility: ?
Time frame: 1 month
Component: Thread Safety
Identify the extensions that are not thread safe by design
or due to dependant libraries and identify them as such.
If possible try to resolve thread safety issue via code
improvements (if php code or patches will be accepted by
library maintainers). For situations where thread safety
cannot easily be acheived a flag in the extension API is
set so PHP can identify non-thread safe extensions. These
extensions will not be loaded in a ZTS compiled binary
(unless it is cli/cgi).
Responsibility: ?
Time frame: ?
Component: SAPI
Environment variables defined in the CGI spec need to be
verified in each SAPI module that they conform to the CGI
spec correctly. If they do not, the SAPI module needs to
fix the variable prior to script execution. Having this
conformity will aid in having PHP scripts run correctly
under different sapi modules.
Responsibility: Shane Caraveo & each sapi module owner
Timeframe: ? (but shouldn't be much effort, most modules are probably ok)
Component: Input Filtering
- Implement a SAPI input filter hook that will get called
just before registering a variable in the
treat_data/post_handler hooks. (done)
- Make sure this is also done in mbstring (done)
- Provide access functions, or perhaps a new
$_RAW_GET/POST/Cookie set of superglobals to get at the
unfiltered data
- Provide a .ini directive which allows people to set their
input filter to one of the built-in strip_tags,
htmlspecialchars or whatever other internal function might
be useful here.
- (The main benefit of this is to make it easier for people
to solve the XSS problem once and for all without having
to go through every line of their code and adding input
validation/filtering everywhere)
Responsibility: Rasmus
Timeframe: Yesterday
Component: RPC Abstraction Layer
Porting java, com, dotnet, xmlrpc, corba, soap and python, srm
(are there more ?) to work with the new oo api and preferably
by using ext/rpc.
Responsibility: Harald
Time frame: 2 months (but i have to wait for a few engine features first)
Component: OO Extensions
Each OO extension has to be revised and rewritten to fit into
the new OO model. We should decide which extensions are a must
to have for the release and which can be ported by the maintainer
later as a separate pecl release.
A list of extensions to be extended that have to be investigated:
* browscap
* aggregate
* all *sql extensions (*_fetch_object)
* domxml (seems like christian is rewriting it anyways)
* ming
Responsibility: Harald (, extension maintainers)
Component: Abstract Data Types (ADT)
Responsibility: Sterling, Harald
Time frame: ?
Component: MySQL Extension
Complete rewrite, leveraging the new MySQL 4 / MySQL 5
features.
Responsibility: Georg Richter, Zak Greant
Timeframe: ?
Component: XML
- Rewrite DOMXML and incorporate all (or most of) W3C-DOM2.
- Use the new ZE2 features (Exceptions, setter/getter).
- Add SAX(2), XML Schema.
- XSLT, HTML, XPath, XPointer, DTD Validation will still be
supported, have to find a meaningful API for it.
- Break BC, warn users now.
- Look at the libxml2 patch by lukas schröder and see if we can prevent
memory leaks with it (anyway, getting rid of mem-leaks and intelligent
memory management is on top prio...)
- In the longer term, domxml (or another name, as with todays features
domxml is a little bit misleading) shall be the main xml-class, which
covers most of what's needed for decent XML support in PHP ;)
But there is certainly place for others like Sablotron etc.
Responsibility: Christian Stocker
Timeframe: ?
Component: Test Suite
Extending the test suite with atleast a test for every
function in an extension that doesn't require external
resources. Also developing an automated test thing which
cvs ups's, compiles and tests the build on a daily base on
as much platforms/extensions as possible.
The test suite will also be extended to support threaded
testing and testing for differing sapi modules (via http
calls or other methods).
Reponsibility: Derick (, extension maintainers)
Time frame: 3 months
|
