Re: [comment] XMLHttpRequest Object - Address Extensibility
On Mon, 24 Apr 2006 07:58:34 +0200, Brad Fults [EMAIL PROTECTED] wrote: That's an unfortunate ripple in that case. Most of what I said assumed that one vendor implemented a feature in a certain way and the rest implemented it in the same way (save for IE). That almost never happens, if ever. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest readystatechange events
On Sun, 23 Apr 2006 23:08:53 +0200, Robin Berjon [EMAIL PROTECTED] wrote: At the moment, Gecko allows adding a single onreadystatechange listener that's notified of changes in readyState. We would like to add the ability to add such listeners via addEventListener; the event name would be readystatechange. So basically this would amount to supporting EventTarget on XHR, right? This has been discussed several times by the WG, and while we like the idea it's pretty much a v2 thing. So why is that? It's not like we can move the current specification that fast to W3C Recommendation. It's also that if we don't do it now v2 isn't so much about cleaning up anymore... rather more reverse engineering. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest progress events
Hi Boris, On Sun, 23 Apr 2006 20:51:03 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: At the moment, Gecko allows adding a single onprogress DOMEventListener that's notified of download progress. We would like to make two changes to the progress event setup: 1) Allow adding progress event listeners via addEventListener, not just via setting the onprogress property. The event name would be progress. This sounds like a good idea. Btw, I found two strange behaviours while looking at it now. It seems like the onprogress event is one cycle before responseText.length. Also, strange things seems to happen if the Content-Length header is missing. Opera will probably wait until this group has made an recommendation because the same behaviour is possible to implement without the onprogress event (by checking the Content-Length header and watching the length of responseText as it progress). 2) Allow adding upload progress event listeners via addEventListener. The event name would be uploadprogress. The timeline for this would be to make the change in development builds in the next several weeks and to ship it hopefully early next year. Does this seem acceptable? If not, are there counter-proposals? I would wait until all vendors get a chance to review a proposal in public. The people that need this behaviour are capable of implementing it today using server side scripting. Is this acceptable? Cheers, - Gorm Eriksen
Re: XMLHttpRequest.responseXML and invalid XML documents
Anne van Kesteren wrote: That bug talks about making the document empty, instead of returning null as the specification says. Those comments predate the specification, no? Is it the plan to follow what the specification says or does it need to be changed for the above reason for example? I don't know. -Boris
Re: XMLHttpRequest progress events
Gorm Haug Eriksen wrote: Btw, I found two strange behaviours while looking at it now. It seems like the onprogress event is one cycle before responseText.length. The interaction between the two in Gecko is undefined and subject to change. Also, strange things seems to happen if the Content-Length header is missing. In this case, the entity size is not known, so progress events report the total downloaded so far, but use the maximum number they can for the total size. At least that's how it should work. Opera will probably wait until this group has made an recommendation because the same behaviour is possible to implement without the onprogress event (by checking the Content-Length header and watching the length of responseText as it progress). Only if you're doing HTTP. There are other protocols supported by XMLHttpRequest (in spite of the name), where getting the content size happens in some other way. Furthermore, even for HTTP your proposal doesn't work for Content-Encoding: gzip. I would wait until all vendors get a chance to review a proposal in public. The people that need this behaviour are capable of implementing it today using server side scripting. Actually, we have consumers that need this behavior that cannot implement it via server-side scripting (e.g. the browser UI and various extensions). I've put this on hold for now while we're discussing it, but we do need to do something along these lines in the next few months at most. -Boris
Re: XMLHttpRequest progress events
On Mon, 24 Apr 2006 18:35:01 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: I would wait until all vendors get a chance to review a proposal in public. The people that need this behaviour are capable of implementing it today using server side scripting. Actually, we have consumers that need this behavior that cannot implement it via server-side scripting (e.g. the browser UI and various extensions). I've put this on hold for now while we're discussing it, but we do need to do something along these lines in the next few months at most. Given that, unlike load, error etc., these are new events it would be useful if you stated what type of interface they would implement, what .bubbles and .cancelable are for the event. So far the only things that are clear from your proposal are .type and .namespaceURI... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest progress events
On Apr 24, 2006, at 9:29 AM, Boris Zbarsky wrote: Maciej Stachowiak wrote: I understand that as an implementor you don't want to sit around waiting for standards bodies to include features in a spec before implementing them. However, since there is an active, open and healthy standards process going on here, you may want to try participating in it more actively before taking that approach. Well, that's what I was trying to do with my initial mail. ;) Here goes: -- Listeners registered for the progress event on the XMLHttpRequest object may receive events implementing the LSProgressEvent interface as data is returned from the server. This event will have a null |input| property. The |totalSize| property will be 0x if the total size is not known. That's not 64-bit clean. In WebKit at least our network library can support correctly reporting progress for files that are larger than 2^32-1. Seems like a bad idea to limit this with large media files and large amounts of memory becoming more and more common. This probably argues against using LSProgressEvent as-is. It's too bad they used unsigned long (which is a 32-bit integer type in OMG IDL). The DOM Level 3 Load Save spec also says: A value of 0 is returned if the total size cannot be determined or estimated. Your proposal for unknown size is incompatible with this. Between this and the always-null input attribute, it seems re-using LSProgress might not be that useful, although using the same names for the applicable attributes may still be a good idea. Listeners registered for the uploadprogress event on the XMLHttpRequest object may receive events implementing the LSProgressEvent interface as the request is sent to the server. This event will have a null |input| property. The |totalSize| property will be 0x if the total size is not known. Implementations are not required to fire these events, but are strongly urged to so that XMLHttpRequest consumers can implement progress indicators as desired. If progress events are fired, there is no specific requirement for how often they should be fired. I think it might be better to define this in a way that has some testable conformance criteria. It's hard to rely on if implementations are allowed to do anything (including send no progress events at all, send them at the wrong time, I realize in this case that's hard to do without needlessly overconstraining the implementation. But here are some requirements that I think might not be unreasonable: 1) You'll get at least one progress event for the full size of the resource. That way you can always use this event alone to make a progress bar, although the granularity may be very poor. 2) If you ask for responseText, you are guaranteed to see at least as much decoded data as the last progress event reported. 3) Might want to define when progress events occur relative to readystatechange events - I'm not sure what this should even be. Regards, Maciej
