Phase II Voting Details

From RuntimeWiki

Jump to: navigation, search

The Phase II voting period is now over (ended on July 13, 2008).

About this page

This wiki page displays Phase 2 Voting details, showing one line for each vote cast for each feature, along with any supplemental comments that the voter entered relative about a particular feature.

Current status

We have completed the voting periods of this initiative (see Timeline at the bottom of Main Page), and are now working on a summary report.

Please help us to continue to perfect the list and the write-ups for the various features. It is OK to add new features to the list if you see something important that is missing. Anyone is welcome to participate. To gain write access, see the instructions at Main Page.

Voting Detail

The following table shows the 37 active feature requests as of the start of the Phase II Voting period. It repeats the summary table from the Feature Requests Summary Page and intersperses one additional line (with purple-colored background) for each vote that was cast on that feature.

FeaturePhase II Votes
#VotesAvgVote (0-10)Total
(#Votes*AvgVote)
Participant Participant's vote (0-10) Comment
 
Security features
 
Better Security for Cross-site Scripts1027.44759.00
JonFerraiolo6Of course this is important, but only gave a 6 because of feature's likely difficulty.
Cwei9 
Kinblas8 
Seshusimhadri10 
Maddesa10 
Gilant6 
Crock10 
Mcp11110 
Ycros2 
Bbuffone8 
Goldjunge7 
Samlie1 
DaveC9 
Rick7 
BradNeuberg8 
GregWilkins8 
NicoleTedesco7Though important, there are multiple avenues to solve this problem, such as considering suggestion for "script archive files" and enable digital signing.
Elvasvj5 
Mikewse5 
Peller8 
Bertrandleroy8 
Gleleu4It should not superseed the best practices on the server-side programming. Educate is better than restrict.
SteveBailey5 
Zionvier9 
DylanSchiemann6 
LudoA9 
Ccmitchellusa7 
ChristopheJolif6 
Weingram10 
Lbirdeau9 
Rabc10 
Phpulse0 
Xelapond10 
Dsanford10 
Whiteinge8 
Novacane4 
RobbieMc7 
Stanjam8 
Bkardell10 
JKoff7 
Ntijerino10 
Toffe10 
Comsymp5 
Buggo8 
Puchat3k6 
Antrax687 
Mis241710 
Saati7 
Giles10 
Kevtufc9 
Mg10 
Silberwoelfin7 
The Mighty Buzzard5 
Alexs9 
Zzen8 
Apostolos3 
Valisystem8 
Daniel1 
Tj1115 
NateRedding10 
Cparadis9 
Tonnzor3 
Jsebrech8 
Smeg4brains4 
TheMadHatter7 
Petrie8 
Jeswinraj8 
PKJedi7 
Chuckanova5 
Dragoncub4 
Cmp9 
Mkantor5 
Fcarbon8 
Hal9 
Giomagi9 
Corneil8 
Liqweed8 
Russell.leggett8 
BaldeepHira6 
Eskatos10 
Chenboyang10 
Maskreddy10 
Mnosal9 
Jbondc10 
SumitShah9 
Libregeek10 
Ikisai10 
RichThompson10 
Sim3 
Odhinnsrunes5 
Trevor.carpenter5 
Diodeus9 
Jhking5 
Dgeorgit10 
Jimmyj7 
Shelleyp9 
Public20085 
Junkafarian9 
Lala10 
Eikenberry7 
Pallieter7 
Jamesdouma8 
 
Stronger Cross-site Request Forgery Protection916.98635.00
JonFerraiolo2The consensus on this issue seems to be that there isn't much browsers can do except not introduce new CSRF attack vectors.
Cwei5 
Kinblas8 
Seshusimhadri0 
Gilant6 
Crock10 
Mcp1119 
Ycros3 
Bbuffone8 
Goldjunge7 
Samlie1 
DaveC9 
Rick7 
BradNeuberg7 
GregWilkins8 
NicoleTedesco4I think the solution to this problem is harder than simply introducing "httpOnly" tags--this requires better site identity control.
Mikewse9 
Peller8 
Bertrandleroy8 
Gleleu7 
SteveBailey7 
Zionvier7 
DylanSchiemann7 
LudoA10 
Ccmitchellusa6 
Phpulse0 
Andr37 
Xelapond10 
Dsanford10 
Whiteinge8 
Novacane5 
RobbieMc7 
Stanjam8 
Bkardell10 
JKoff8 
Comsymp5 
Buggo8 
Puchat3k5 
Antrax688 
Mis24178 
Saati6 
Kevtufc7 
Mg6 
Silberwoelfin7 
The Mighty Buzzard5 
Alexs9 
Zzen7 
Apostolos6 
Valisystem8 
Daniel2 
Tj1115 
NateRedding9 
Cparadis10 
Tonnzor3 
Jsebrech7 
Smeg4brains4 
TheMadHatter7 
Petrie8 
Jeswinraj8 
PKJedi7 
Chuckanova6 
Dragoncub4 
Cmp2 
Mkantor6 
Fcarbon10 
Hal5 
Giomagi8 
Corneil8 
Russell.leggett8 
BaldeepHira6 
Eskatos10 
Chenboyang10 
Maskreddy10 
Mnosal10 
Jbondc10 
SumitShah8 
Libregeek10 
Ikisai9 
RichThompson10 
Sim5 
Odhinnsrunes5 
Trevor.carpenter5 
Diodeus9 
Jhking8 
Dgeorgit10 
Jimmyj5 
Public20087 
Lala10 
Eikenberry6 
Pallieter7 
Jamesdouma7 
 
Better IFrames Better Sandboxing916.03549.00
JonFerraiolo7Of course this is important, but only gave a 7 because of feature's likely complexity and difficulty.
Cwei9 
Kinblas8 
Seshusimhadri7 
Gilant7 
Crock10 
Mcp1118 
Bbuffone8 
Goldjunge1 
Samlie1 
DaveC7 
Rick2 
BradNeuberg9 
SamuelSantos8 
GregWilkins7 
NicoleTedesco4This is more of a development effort reduction solution than a security one.
Mikewse5 
Peller8 
Bertrandleroy8 
Gleleu4 
SteveBailey5 
Zionvier7 
DylanSchiemann2 
LudoA10 
Ccmitchellusa4 
ChristopheJolif1 
Weingram10 
Phpulse0 
Xelapond6 
Dsanford8 
Novacane2 
RobbieMc5 
Stanjam8 
Bkardell4 
JKoff5 
Toffe8 
Buggo6 
Puchat3k4 
Antrax6810 
Mis241710 
Saati6 
Giles2We need a decent access and authorization model, not sandboxing. Often we don't want to sandbox.
Kevtufc7 
Mg10 
Silberwoelfin7 
The Mighty Buzzard5 
Alexs9 
Zzen8 
Apostolos5 
Valisystem6 
Daniel1 
Tj1115 
NateRedding5 
Cparadis8 
Tonnzor5 
Jsebrech4 
Ngtele5 
Smeg4brains2 
Jeswinraj9 
PKJedi2 
Chuckanova8 
Cmp2 
Sadie6 
Mkantor8 
Simbaking37 
Fcarbon7 
Hal6 
Giomagi6 
Corneil8 
Liqweed8 
Russell.leggett6 
BaldeepHira4 
Eskatos4 
Chenboyang9 
Maskreddy9 
Mnosal6 
SumitShah6 
Libregeek8 
Ikisai5 
RichThompson7 
Sim1 
Odhinnsrunes7 
Trevor.carpenter3 
Diodeus5 
Jhking2 
Dgeorgit10 
Public20084 
Lala10 
Eikenberry7 
Pallieter8 
Jamesdouma8 
 
Native JSON Parsing1076.43688.00
JonFerraiolo10Small amount of implementation effort, but with large benefits in terms of performance and security
Kinblas7 
Gilant8 
Crock10 
Mcp11110 
Savetheclocktower6 
Ycros3 
Bbuffone5 
Goldjunge10 
Samlie3 
DaveC8 
Rick2 
BradNeuberg8 
SamuelSantos10 
GregWilkins7 
NicoleTedesco9Not only is this a security fix, but may also prove to be a nice performance enhancement solution. A "two-fer!"
Mikewse5 
Peller8 
Bertrandleroy7 
Gleleu10I would also ask for a better support of ticket assertion, HTTP 1.1 authentication in JS, etc.
SteveBailey2 
Zionvier5 
Naos7 
DylanSchiemann9 
Ccmitchellusa3 
ChristopheJolif6 
Weingram6 
Lbirdeau9 
DarkDust8 
Phpulse0 
MincerLightbringer7 
Andr310 
Xelapond0 
Dsanford8 
Whiteinge8 
Novacane4 
RobbieMc8 
Kleite5 
Stanjam8 
Bkardell10 
JKoff4 
Pixelblender10 
Toffe9 
Buggo8 
Puchat3k7 
Antrax687 
Mis24176 
Saati7 
Giles4 
Kevtufc4 
Kedder4 
Mg5 
Silberwoelfin7 
Coldnebo0 
The Mighty Buzzard10 
Alexs5 
Zzen7 
Apostolos10 
Valisystem10 
Daniel2 
Tj1119 
NateRedding7 
Cparadis8 
Tonnzor5 
Jsebrech4 
Smeg4brains1 
Jeswinraj5 
Paziek0CrossSite XML will be just fine, and safe from malicious code
PKJedi7 
Chuckanova8 
Cmp2 
Sadie5 
Mkantor5 
Stevenally6 
Sebwin7 
Yaakov7That's not only a security feature: JSON is a very usable standard for client-server communication; more efficient than xml.
Fcarbon9 
Hal7 
Giomagi5 
Corneil8 
Fredck10 
Russell.leggett10 
BaldeepHira9 
Eskatos5 
Chenboyang5 
Mnosal8 
Jbondc6 
SumitShah9 
Libregeek9 
Ikisai6 
RichThompson6 
Sim4 
Odhinnsrunes4 
Trevor.carpenter1 
Diodeus4 
Jhking10 
InfoSec8127 
Dgeorgit7 
Shelleyp6 
Public20080 
Junkafarian7 
Lala8 
Saleem10Instead of framework JavaScript libraries providing JSON parsing routines, the browsers should provide native support.
Eikenberry7 
Pallieter4 
Jamesdouma7 
Johan9 
 
Client-server communications features
 
The Two HTTP Connection Limit Issue987.04690.00
JonFerraiolo9Browser vendors need to be sure to read the detailed comments where people say that simply raising the limit from 2 to 6 is not sufficient
Cwei9 
Kinblas6 
Maddesa7 
Gilant7 
Crock9 
Savetheclocktower6 
Bbuffone4 
Goldjunge4 
Samlie2 
DaveC8 
Rick10 
BradNeuberg9 
SamuelSantos10 
GregWilkins10To better share the 2 connections between frames - not to increase the limit
NicoleTedesco7Though performance is important in general, I would rather prioritize improvements to "basic" features (e.g., Array manipulation) over performance for the "extras."
TedGoddard10Allow Pipelining to be specified through the XMLHttpRequest API. Enforce connection limit per frame, not per browser (use Safari policy as example).
Mikewse8 
Bertrandleroy6 
Gleleu10It is a major issue for building user's dashboard with multiple sources.
SteveBailey9 
Zionvier10 
Andyed6 
DylanSchiemann9 
LudoA10 
Ccmitchellusa6 
ChristopheJolif10 
Weingram8 
Ondras6 
Lbirdeau10 
DarkDust5 
Phpulse2 
Xelapond0 
Novacane8 
RobbieMc10 
Kleite6 
Bkardell10 
JKoff4 
Buggo6 
Puchat3k10 
Antrax6810 
Mis24178 
Saati5 
Mg0 
Samson7 
The Mighty Buzzard5 
Alexs9 
Zzen7 
Apostolos7 
Valisystem9 
Daniel5 
Tj1116 
NateRedding7 
Cparadis6 
Tonnzor9 
Jsebrech9 
Ngtele7 
Smeg4brains9 
Mauricev8 
TheMadHatter5 
Petrie8 
Jeswinraj9 
Paziek4 
PKJedi8 
Chuckanova3 
Dragoncub6 
Cmp9 
Sadie5 
Mkantor7 
Stevenally6 
Fcarbon9 
Hal7 
Giomagi1 
Corneil7 
Liqweed9 
Russell.leggett4 
BaldeepHira5 
Eskatos10 
Chenboyang10 
Maskreddy9 
Mnosal5 
Jbondc8 
SumitShah8 
NikunjMehta0This limit is imposed by browsers because of the IETF RFC 2616 language of not creating more than two connections per user agent to a server. Unless that text is changed, I find it hard to see browsers changing this policy.
Libregeek7 
Ikisai4 
RichThompson9 
Odhinnsrunes9 
Trevor.carpenter6 
Diodeus9 
Jhking6 
Shelleyp8 
Public20086 
Mog010 
Eikenberry9 
Pallieter5 
Jamesdouma5 
Johan6 
 
Persistent Connections Issue956.83649.00
JonFerraiolo9 
Cwei9 
Kinblas6 
Seshusimhadri7 
Crock8 
Savetheclocktower6 
Bbuffone7 
Goldjunge10 
Samlie4 
DaveC8 
Rick8 
BradNeuberg7 
SamuelSantos8 
GregWilkins8 
NicoleTedesco7Though performance is important in general, I would rather prioritize improvements to "basic" features (e.g., Array manipulation) over performance for the "extras."
TedGoddard10 
Mikewse9 
Bertrandleroy6 
Gleleu0Wrong way to implement a push mechanism. Not in line with the SOA best practices (stateless state recommended). A listener (as an object) would be more appropriate.
SteveBailey7 
Zionvier8 
DylanSchiemann8 
LudoA10 
Ccmitchellusa7 
ChristopheJolif9 
Weingram8 
Lbirdeau9 
Phpulse0imagine persistent connections with a slashdotting.
Sabelkac7 
Xelapond10 
Novacane8 
RobbieMc10 
Kleite7 
Bkardell4 
JKoff4 
Pixelblender7 
Buggo6 
Puchat3k7 
Antrax688 
Mis24176 
Saati5 
Mg6 
Samson9 
The Mighty Buzzard0 
Alexs9 
Zzen5 
Apostolos7 
Valisystem10 
Daniel4 
Tj1116 
NateRedding8 
Cparadis7 
Tonnzor9 
Jsebrech6 
Ngtele7 
Smeg4brains9 
Mauricev8 
TheMadHatter5 
Petrie8 
Jeswinraj7 
Paziek7 
PKJedi8 
Chuckanova4 
DirkReiners10 
Cmp5 
Sadie5 
Mkantor5 
Fcarbon7 
Hal6 
Giomagi4 
Corneil5 
Liqweed9 
Russell.leggett8 
BaldeepHira4 
Eskatos4 
Chenboyang10 
Maskreddy8 
Mnosal6 
Jbondc6 
SumitShah6 
NikunjMehta9The persistent connections feature of HTTP 1.1 has been around for a long time and enables a lot of batch and feed processing.
Libregeek6 
Ikisai4 
RichThompson8 
Odhinnsrunes9 
Trevor.carpenter6 
Diodeus6 
Jhking2 
InfoSec8126 
Public20088 
Mog08 
Tabrez9 
Eikenberry8 
Pallieter5 
Jamesdouma6 
 
XHR Connection Length Advice644.81308.00
JonFerraiolo9This seems like a good candidate for how to achieve better server push (persistent connections).
Cwei4 
Kinblas2 
Crock7 
Bbuffone7 
Goldjunge6 
Samlie5 
DaveC6 
Rick4 
BradNeuberg2 
GregWilkins8 
NicoleTedesco7Though performance is important in general, I would rather prioritize improvements to "basic" features (e.g., Array manipulation) over performance for the "extras."
Mikewse3 
Bertrandleroy0 
Gleleu4 
SteveBailey7 
Zionvier9 
DylanSchiemann7 
Ccmitchellusa4 
Weingram3 
Lbirdeau9 
Novacane7 
RobbieMc8 
Bkardell2 
JKoff3 
Puchat3k8 
Antrax688 
Mis24176 
Saati5 
The Mighty Buzzard0 
Alexs0 
Zzen4 
Apostolos9 
Valisystem5 
Daniel4 
Tj1113 
Cparadis3 
Tonnzor2 
Jsebrech1 
Smeg4brains3 
Jeswinraj5 
Paziek4 
DirkReiners7 
Cmp5 
Sadie3 
Mkantor2 
Fcarbon6 
Hal7 
Corneil5 
BaldeepHira4 
Eskatos0 
Maskreddy7 
Mnosal5