Re: [eventsource] Moving Server-sent Events spec back to Last Call
On Thu, 10 Mar 2011 21:06:47 +0100, Ian Hickson i...@hixie.ch wrote: Can I ask you to create a TODO file in that directory that lists the cases I suggested that aren't tested? That way at least my ideas don't get lost, even if we don't have tests for them straight away. :-) Good point! http://tc.labs.opera.com/apis/EventSource/todo.txt -- Anne van Kesteren http://annevankesteren.nl/
Re: [eventsource] Moving Server-sent Events spec back to Last Call
On Sat, 12 Mar 2011, Anne van Kesteren wrote: ! On Thu, 10 Mar 2011 21:06:47 +0100, Ian Hickson i...@hixie.ch wrote: Can I ask you to create a TODO file in that directory that lists the cases I suggested that aren't tested? That way at least my ideas don't get lost, even if we don't have tests for them straight away. :-) Good point! http://tc.labs.opera.com/apis/EventSource/todo.txt Thanks! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [eventsource] Moving Server-sent Events spec back to Last Call
On Fri, 25 Feb 2011 16:49:28 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 25 Feb 2011, Anne van Kesteren wrote: Test suite is pretty much finished (I have a few things left to clean up and need to put it on w3c-test.org now that it accepts PHP): I think I will postpone doing this. It only increases the amount of places I have to keep updated while giving very little in return. http://tc.labs.opera.com/apis/EventSource/ The source is still accessible here: http://tc.labs.opera.com/svn/apis/EventSource/ At least this test needs updating for recent changes: http://tc.labs.opera.com/apis/EventSource/request-2xx.htm It has been removed and request-status-error.htm has been updated to make sure 2xx response codes behave similar to other failures. (Thanks to Pablo Flouret.) The test suite seems very short for the spec... in particular, it doesn't seem to test the parsing of the event format very well. Anything in particular you think needs testing? But it's hard to say for sure without seeing the source of the support files. See above. Also, the tests seem to rely on a big external file, which is generally bad practice, but I'm not familiar enough with the test harness to be able to tell whether this is a real problem or not. Personally I prefer test harnesses that keep well out of the way, e.g. by using parent.test() to report results -- for example, see: http://www.hixie.ch/tests/adhoc/html/parsing/encoding/001.html ...which works fine as a stand-alone test (and has no external dependencies) but can also work in a harness: http://www.hixie.ch/tests/adhoc/html/parsing/encoding/all.html I probably shouldn't be whining about tests though given that I didn't write any for this spec. :-) I do not really care about the format that much. For automated testing a harness is useful and vendors seem to be somewhat willing to converge on something that can be used for most of our tests. -- Anne van Kesteren http://annevankesteren.nl/
Re: [eventsource] Moving Server-sent Events spec back to Last Call
On Mon, 7 Mar 2011, Anne van Kesteren wrote: The test suite seems very short for the spec... in particular, it doesn't seem to test the parsing of the event format very well. Anything in particular you think needs testing? Zero, one or two BOMs before an event. Parsing of comments with zero, one, or 2049 bytes of content, on either side of a real field. Handling of unknown fields. Handling of fields with names similar to but not identical to valid fields, in particular with spaces, hyphens, underscares, nulls where they're not expected; with uppercase names instead of lowercase ones; with turkish upper-case dotted Is where a lowercase i is expected. Fields with and without value parts, for each allowed field and for illegal fields. Fields with and without spaces after their colons. End of line handling: cr/lf/cr, lf/cr/lf, etc. Event dispatch when the last field ends with eof. Nulls in values. Surrogate halves in field names and values. UTF-8 errors in field names and values. Retry field with leading zeros that are binary and octal (011, 071), with hex values (0x01), with non-numeric trailing garbage (123x). Also, the tests seem to rely on a big external file, which is generally bad practice, but I'm not familiar enough with the test harness to be able to tell whether this is a real problem or not. Personally I prefer test harnesses that keep well out of the way, e.g. by using parent.test() to report results -- for example, see: http://www.hixie.ch/tests/adhoc/html/parsing/encoding/001.html ...which works fine as a stand-alone test (and has no external dependencies) but can also work in a harness: http://www.hixie.ch/tests/adhoc/html/parsing/encoding/all.html I probably shouldn't be whining about tests though given that I didn't write any for this spec. :-) I do not really care about the format that much. For automated testing a harness is useful and vendors seem to be somewhat willing to converge on something that can be used for most of our tests. I've no problem with a harness, my problem is just that the tests require the harness to run. I prefer tests that are standalone but when used in a harness can report errors to their harness. But that's just a personal preference. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [eventsource] Moving Server-sent Events spec back to Last Call
On Thu, 24 Feb 2011 21:24:01 +0100, Arthur Barstow art.bars...@nokia.com wrote: Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. Are there any objections to doing the above? Test suite is pretty much finished (I have a few things left to clean up and need to put it on w3c-test.org now that it accepts PHP): http://tc.labs.opera.com/apis/EventSource/ Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
Re: [eventsource] Moving Server-sent Events spec back to Last Call
On Fri, 25 Feb 2011, Anne van Kesteren wrote: On Thu, 24 Feb 2011 21:24:01 +0100, Arthur Barstow art.bars...@nokia.com wrote: Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. Are there any objections to doing the above? Test suite is pretty much finished (I have a few things left to clean up and need to put it on w3c-test.org now that it accepts PHP): http://tc.labs.opera.com/apis/EventSource/ At least this test needs updating for recent changes: http://tc.labs.opera.com/apis/EventSource/request-2xx.htm The test suite seems very short for the spec... in particular, it doesn't seem to test the parsing of the event format very well. But it's hard to say for sure without seeing the source of the support files. Also, the tests seem to rely on a big external file, which is generally bad practice, but I'm not familiar enough with the test harness to be able to tell whether this is a real problem or not. Personally I prefer test harnesses that keep well out of the way, e.g. by using parent.test() to report results -- for example, see: http://www.hixie.ch/tests/adhoc/html/parsing/encoding/001.html ...which works fine as a stand-alone test (and has no external dependencies) but can also work in a harness: http://www.hixie.ch/tests/adhoc/html/parsing/encoding/all.html I probably shouldn't be whining about tests though given that I didn't write any for this spec. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [eventsource] Moving Server-sent Events spec back to Last Call
Hi Ian, All, Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. Are there any objections to doing the above? -Art Barstow On Feb/14/2011 5:22 AM, ext Ian Hickson wrote: On Sat, 12 Feb 2011, Arthur Barstow wrote: Regarding re-publishing the Server-sent Events spec [ED] as a new Last Call Working Draft ... 1. 11835 - EventSource must support cross-domain requests (ala CORS) http://www.w3.org/Bugs/Public/show_bug.cgi?id=11835 This will be supported once CORS is more widely deployed and understood by content developers. At a guess, 9 to 24 months. 2. 11836 - Don't specify the transport, just specify API and protocol http://www.w3.org/Bugs/Public/show_bug.cgi?id=11836 It's not clear to me what problem this bug describes, so I cannot currently give a timeline for its resolution. Discussion is ongoing. HTH,
Re: [eventsource] Moving Server-sent Events spec back to Last Call
On Sat, 12 Feb 2011, Arthur Barstow wrote: Regarding re-publishing the Server-sent Events spec [ED] as a new Last Call Working Draft ... 1. 11835 - EventSource must support cross-domain requests (ala CORS) http://www.w3.org/Bugs/Public/show_bug.cgi?id=11835 This will be supported once CORS is more widely deployed and understood by content developers. At a guess, 9 to 24 months. 2. 11836 - Don't specify the transport, just specify API and protocol http://www.w3.org/Bugs/Public/show_bug.cgi?id=11836 It's not clear to me what problem this bug describes, so I cannot currently give a timeline for its resolution. Discussion is ongoing. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
