HTTP Streaming testing results

[krem]

But the point that you are missing, and the reason why the IFRAME solution is really good for some implementations, is that the XMLHTTPRequest object in IE doesn't raise an event when a chunk of data is sent. That's why originally many people preferred the hidden IFRAME solution.

However, IE has recently come out with X-DomainRequest object. I haven't used it yet, but hopefully it'll take care of it's poor implementation of the XMLHTTPRequest object.

[York]

"But the point that you are missing"

Right, I keep on forgetting about the IE XHR implementation. I'm not too familiar with browser differences.

[krem]

(05-25-2010 09:26 AM)York Wrote:  "But the point that you are missing"

Right, I keep on forgetting about the IE XHR implementation. I'm not too familiar with browser differences.

Basically, IE 7 and 8 do not raise the onreadystatechanged event for readyState = 3 when it receives data chunks, like most other browsers do and the W3 standard states.

[York]

Is it a bug or an intentional problem created by Microsoft as per usual?

[York]

(05-25-2010 02:35 AM)krem Wrote:  In this particular case, it would suffer from the same issue in IE since it would be using IE's XHR and resulting in no event being triggered for ready state 3.

As I played around with different techniques, I did find that there are better alternatives to the IFRAME within each browser, but they all have to be implemented differently. Remember the idea is to have the content stream back to the client and not have the client polling the server too much within a single second or minute.

Quote:Why not use an existing library like jQuery to handle data transportation? Then you can encode your output as a JSON object (json_encode) and have jQuery handle it natively.

Also jquery leaks memory like a sieve leaks water.

I think in the end the best option would be to implement multiple solutions into one giant kludge of a library (that will never hopefully need to be touched afterward) and utilize each implementation based on the client's browser.

So the general solutions are something along the lines of Iframes, XHR, Flash proxy.

[krem]

What I have often seen done as well as attempted myself is dynamically loading script files based on the browser. The concept is not new and can be implemented on either the server or the client (browser).

The script files would contain browser specific implementations of the functionality in question. All versions would implement the same interface so cross-dependent JavaScript files wouldn't need to be modified. It's basic Abstraction 101, but with JavaScript

[York]

I found an interesting link, although, being unfamiliar with web technologies I am unsure of its usefulness.

http://www.devx.com/DevX/Article/8155

REST versus SOAP. Whats your take on the matter and how it applies to an AJAX-based MUD?

[krem]

(06-24-2010 11:58 AM)York Wrote:  I found an interesting link, although, being unfamiliar with web technologies I am unsure of its usefulness.

http://www.devx.com/DevX/Article/8155

REST versus SOAP. Whats your take on the matter and how it applies to an AJAX-based MUD?

Well, in all reality, you will most likely never ever use SOAP in a browser-based game, unless you really like to cause yourself pain. It defines way too much overhead to do simple things.

REST, on the other hand, is much more simple and straight forward. I'm not a huge fan of using 'resources' as the target of the action, but I see how and why it defines what it does. A resource is uniquely identified via a URL.
[FYI: when referring to a resource, just think of resource being any type of data or information]

With REST, you are basically going back to the original definition of the HTTP protocol and using it properly. I try to stay inline with that in my works, but I often don't.

REST basically defines that you use the 4 main HTTP actions for a single purpose:

• POST - creates a resource. This is different than modifying a resource
• GET - gets a resource. The result of a GET should never end up modifying a resource
• PUT - modifies a resource.
• DELETE - deletes a resource.
  

This is the equivalent of CRUD (create, read, update, delete) for data storage.

Here's more resources on the subject of SOAP vs REST:
http://www.ioncannon.net/meta/117/soap-vs-rest/