type http does not work in chrome and opera and some more improvments

[GoogleCodeExporter]

What steps will reproduce the problem?
1. use chrome or opera and set type to 'http'
if have debuged and found out:

message.size is NaN afeter first loop, but you check if message.size == null 
and you go never into the 'IF'. How ever, i have reimplemented your complete 
handleMessage-function in a (maybe?) more reobust way.

the next problem was, sometimes, if the server quits the connection and the 
client makes no reconnect but you refresh the page with F5, sometimes, the new 
page becomes an old chung of data, can't explain that. so i have optimized the 
function to handle messages in other way.

mesasge format:
#3        abc
#12       abcdefghijkl
#15       abcdefghijklsdfsdfsdf

between # and the data begin are always 10 chars, doent matter how much the 
size of the size is.

on server side and client side, i escape the '#' to an custom format.

function body:

var sizeBegin = text.indexOf('#', message.index);
var sizeSize = 10;

if (sizeBegin < 0) return false;

if (message.size == null && text.length - sizeBegin >= sizeSize + 1) {
  var sizeStr = $.trim(text.substr(sizeBegin + 1, sizeSize));
  message.size = +sizeStr;
}

var dataBegin = (1 + sizeBegin + sizeSize);
if (text.length - dataBegin >= message.size) {
  message.data = text.substr(dataBegin, message.size);
  message.index = dataBegin + message.size;

  // Completes parsing
  delete message.size;

  return true;
}
else {
  return false;
}

Original issue reported on code.google.com by sebastia...@gmail.com on 21 Jul 2011 at 5:20

[GoogleCodeExporter]

okay, my colution does not set the metadata.id, but this should not be the 
biggest problem. you can take the "first" message and the mesasgedata-body 
could be the metadata.id.

for example: 
#4         7865
#1024      spacer.....
#7         data...

Greetings

Original comment by sebastia...@gmail.com on 21 Jul 2011 at 5:24

[GoogleCodeExporter]

Okay, my version was to simple, i forgot, that sometimes only small chungs are 
delivered. So here is a better parser(it's for the current release 1.1):

for (; ; ) {

  var NONE = 0
  var SIZE = 1;
  var DATA = 2;

  var msg = this.message;

  if (typeof msg.state == "undefined") msg.state = NONE;

  if (text.length == 0) return;

  var readChunk = function (text, msg) {
    var data = text.substr(msg.index, msg.size - msg.data.length);
    if (data.indexOf('#') > 0) {
      msg.state = NONE;
    }
    else {
      msg.data += data;
      msg.index += data.length;
    }
  }

  if (text.indexOf('type') >= 0) {
    var debug = 1;
  }

  if (msg.state == NONE) {
    var sizeBegin = text.indexOf('#', msg.index);
    if (sizeBegin < 0) return false;
    msg.state = SIZE;
    msg.size = 10;
    msg.data = '';
    msg.index = sizeBegin + 1;
  }

  if (msg.state == SIZE) {
    readChunk(text, msg);
    if (msg.data.length == msg.size) {
      msg.size = +msg.data;
      msg.data = '';
      msg.state = DATA;
    }
  }

  if (msg.state == DATA) {
    readChunk(text, msg);
    if (msg.data.length == msg.size) {
      msg.state = NONE;

      if (this.readyState < 3) {
        // Pseudo MessageEvent
        this.trigger("message", {
          data: this.message.data,
          origin: "",
          lastEventId: "",
          source: null,
          ports: null
        });
      }

      // Resets the data and size
      this.message.size = null;
      this.message.data = "";

      return true;
    }
  }

  return false;
}

Original comment by sebastia...@gmail.com on 22 Jul 2011 at 12:16

[GoogleCodeExporter]

Hello

Above all, 'the new page becomes an old chung of data'? I can't understand 
about old chunk and refreshing, and it looks like the source of the problem. 
Could you elaborate more on that? New format and parser are good, but more 
importantly the prerequisite of parsing is the valid response.

As a result, the fact that the value of the message.size is NaN means that the 
response fragment being parsed is invalid, and there is nothing we can do. This 
issue basically cannot be solved by replacing format and parser.

Donghwan

Original comment by flowersi...@gmail.com on 23 Jul 2011 at 7:01

[GoogleCodeExporter]

Hello Donghwan,
okay, i can't test it anymore, because i'm using an custom format.

Some points of mind, independed of that if you are already handle it or not, 
only some points of mind:
- the client should handle the "possibility" of bad responses. Not in all cases 
the servers can garantee correct responses. If that, the client should not 
hang, it should "disconnect".
- Keep in mind to have never infinity loops and have always an 
.abort/.termindate implementation, so that "antoher" js-timer can check the 
healthy of the stream, like in Issue 25 from me.
- my message format has the following better thing: The '#' are stop-markers. 
If i find a new one untill parsing, i discard the current parsing an parse a 
new messsage. You don't need to use my implemantation - you can add a event 
"onDataChunkAvailable", with an attached message{data, index). If passed 
"onDataChunkAvailable" != null, you use the custom message parser.

Greetings from German,
Sebastian

Original comment by sebastia...@gmail.com on 23 Jul 2011 at 9:38

[GoogleCodeExporter]

You're right. I'll close stream when the response gets out of control.

Although your format is good and flexible to handle various situation, the 
default format won't be changed for backward compatibility, and there is no 
problem with correct response.

Incidentally, what does 'onDataChunkAvailable' event exactly mean?

Thanks for your advice, I'll deal with them case by case.

Original comment by flowersi...@gmail.com on 24 Jul 2011 at 10:40

• Changed state: Started
• Added labels: Target-1.2

[GoogleCodeExporter]

Hello Donghwan,
as i understoof your source better now, and i read issue 5, i would say, that 
you already implemented yet. onDataChunkAvailable would be the same as 
handleMessage, so forget my onDataChunkAvailable;

As i understood correctly, i can set the handleMessage and implement there my 
own parser. I would take your latest version, but there's a problem in the 
moment, please see my issue 24. Maybe with this improvement: issue 19.

Greetings from Germany,
Sebastian

Original comment by sebastia...@gmail.com on 24 Jul 2011 at 10:51

[GoogleCodeExporter]

I found that it's possible to validate response, but code is somewhat 
cumbersome considering the low frequency of being executed. Besides, as the 
valid response is a prerequisite of default handlers for processing, such a 
defensive code will not be executed if the user meets it.

Nevertheless, if needed, user can directly handle it by implementing request 
handlers such as handleOpen and handleMessage.

Original comment by flowersi...@gmail.com on 24 Jul 2011 at 2:24

• Changed state: WontFix
• Removed labels: Target-1.2