Bug Tracker

Changes between Initial Version and Version 1 of Ticket #9883, comment 11


Ignore:
Timestamp:
Dec 7, 2012, 9:51:35 AM (7 years ago)
Author:
jaubourg
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #9883, comment 11

    initial v1  
    1 FYI, preliminary study indicates adding a minimal implementation of a progress callback which the xhr transport would call at each readystate with the native xhr instance as sole parameter (so that it can be inspected and used) is in the vicinity of 30bytes min/gzipped. Any attempt to make it more secure (not expose the native xhr directly) or more useful (call the progress handlers with meaningful parameters) can only make it much bigger and is actually the disirable approach.
     1FYI, preliminary study indicates adding a minimal implementation of a progress callback which the xhr transport would call at each readystate with the native xhr instance as sole parameter (so that it can be inspected and used) is in the vicinity of 30bytes min/gzipped. Any attempt to make it more secure (not expose the native xhr directly) or more useful (call the progress handlers with meaningful parameters) can only make it much bigger and is actually the desirable approach.
    22
    33I'm quite torn here, because I know how useful it would be yet I feel like it will be too much weight at this point. Since I know the xhr transport will be extremely simplified for 2.x, I'd like to postpone this.