In a nutshell, this policy prevents pages from two different domains from modifying each others properties, using XMLHttpRequest, setting cookies etc. For instance, Example.com and OtherExample.com can't get references to each others document properties and can't set cookies on each other. Additionally, Example.com can't use XMLHttpRequest (aka AJAX) to load a resource from OtherExample.com. This last bit is probably the biggest issue for developers today -- in todays world of open web services and mashups. How do you consume a web service with Javascript if you can't load the data properly?

Solution 1: Use a server-side proxy

The first way around this problem is to use a very simple server-side script that acts as a proxy to the web service. So instead of requesting AJAX from the remote site, you request it locally on your own domain through the proxy. The proxy itself has it's programming logic to send your request off to the remote site, gather the data, and then serve it back to you.

.________________________.
| Client on YourSite.com |
'-\/---------/\----------'
  ||         ||
  ||_________||__.
  | AJAX Request |
  '---\/-----/\--'
      ||     ||
      ||_____||______________.
      | YourSite.com         |
      | (Ex. ajax_proxy.php) |
      '---\/-----/\----------'
          ||     ||
          ||_____||__________.
          | OtherSite.com    |
          '------------------'

Since your server-side script has no qualms about fetching data from another domain, you can successfully proxy all AJAX like this without running into any trouble. And then since the client browser is fetching the data from the local domain (even though you're making another request behind the scenes), it doesn't violate the same origin policy.

An example proxy script might look something like this (maybe a little more complex if you're handling POST data too):

$url = 'http://othersite.com/someservice?' . http_build_query($_GET);
echo file_get_contents($url);

Remember, the sole purpose of the proxy is just so the client browser can load the data locally on the same domain so the same origin policy isn't violated.

Drawbacks

This method works well but has two obvious drawbacks. First is of course that you need a server-side script at all. Especially if you are providing a service, this raises the barrier for entry and makes it harder for "noobs" to use your widget -- it's not a simple "paste this code into your footer" instruction; you also need to explain how to install the proxy service.

The second drawback is that your own servers are making these requests which makes the whole process slower, but also eats up your resources -- both your processing power and even just simple bandwidth.

Solution 2: JSONP

The second solution is to use JSONP -- "JSON with Padding." This is a technique that lets you get around the same origin policy. In order to use JSONP, the service you are requesting needs to support it.

So in the last solution, the consumer (the user using the service) required an ajax_proxy.php or whatever server-side proxy script. In this solution, the provider (Digg, Amazon, Yahoo -- whatever) needs to support JSONP themselves. Thankfully, these days the idea is catching on and it's likely JSONP is an option. And if you're a service provider, then you'll want to build it in to your service for sure.

How it works

A normal JSON request is sent using XMLHttpRequest and the reply looks something like this:

{'uid': 23, 'username': 'Chroder', 'name': 'Christopher Nadeau'}

Now the truth is, JSONP isn't AJAX at all technically speaking because it does not use XMLHttpRequest. JSONP requests are made by dynamically inserting a <script> tag into the DOM. For example, you'd insert this:

<script type="text/javascript" src="http://othersite.com/service?all=your&params=as&usual=gohere"></script>

Then that remote Javascript file is loaded and contains an actual Javascript function call. For example:

handleJsonReply({'uid': 23, 'username': 'Chroder', 'name': 'Christopher Nadeau'});

In other words, instead of reading AJAX data directly into a variable in Javascript, you define a callback function that is called when the data arrives, and the first parameter is the data itself as an object literal. If you were a provider implementing JSON on your service you might have something like:

// A service provider accepts a 'callback' parameter
// that it uses to wrap an AJAX reply

// Imagine we did some work here
$json = json_encode($mydata);

// Using JSONP
if ($_GET['callback']) {
	echo $_GET['callback'] . "($json);"; // somefunction({data here});

// Normal JSON
} else {
	echo $json;
}

The Javascript source code result of that request is nothing but a real executable function call with a Javascript object literal. It's as if you added the tag yourself and it called some functions -- the difference being that the JS is written by the producer on-the-fly and embeds the data you want right in the code. This is why it all works; it's not actually AJAX at all, it's just loading a remote Javascript file that happens to have some useful data in it.

Using a library like jQuery that supports JSONP, these details of inserting the special script tag and creating the special callback function are all taken care of automatically. Using a JS library, usually the only difference between JSONP and real AJAX is that you enable a 'jsonp' option.

Drawbacks

The first limitation to this method is that you have to rely on the provider to implement JSONP. The provider needs to actually support JSONP -- they need to wrap their JSON data with that callback function name.

Then the next limitation -- and this is a big one -- is that JSONP doesn't support POST requests. Since all data is passed in the query string as GET data, you are severely limited if your services require the passing of long data (for example, forum posts or comments or articles). But for the majority of consumer services that fetch more data than they push, this isn't such a big problem.

JSONP with jQuery

Step 1: Make sure the provider supports JSONP.
Step 2: Set the dataType option to jsonp, and if the provider uses a different GET param other than 'callback', specify the jsonp option to that parameter name.

$.ajax({
    // ... Use the AJAX utility as you normally would
    dataType: 'jsonp',
    // ...
});

jQuery will generate a unique callback name for this request (something like json1268267816). Thus, the reply from a web service would be something like:

json1268267816({'uid': 23, 'username': 'Chroder', 'name': 'Christopher Nadeau'});

But jQuery handles it all seamlessly, so you as the developer just handle it like a normal AJAX request using the same jQuery success/failure/complete callback hooks.

What are stream wrappers?

PHP 4.3.0 introduced the idea of streams. The PHP manual has a perfect explanation:

Streams were introduced with PHP 4.3.0 as a way of generalizing file, network, data compression, and other operations which share a common set of functions and uses. In its simplest definition, a stream is a resource object which exhibits streamable behavior. That is, it can be read from or written to in a linear fashion, and may be able to fseek() to an arbitrary locations within the stream.

Streams are identified by a particular scheme in the URI. For example, with http://someurl the scheme is 'http' and when no scheme is provided like in /file.php, the scheme is defaulted to 'file' and is expected to be a file in the filesystem (thus file:///file.php would mean the same thing).

Stream wrappers are bits of code that tell PHP how to handle certain schemes. The interesting thing is that you can create your own custom stream wrappers written in PHP with little effort.

For example, you may have done file_get_contents('file.txt'); before. But say you wanted to have the same ease of use but with data from a different source. You could create a custom stream wrapper to get data from wherever you want and use all of the normal PHP functions as usual: file_get_contents('mystream://whatever');.

Almost any function that works on files will work with custom stream wrappers. That includes fopen, fwrite, fseek, is_readable, is_writable, stat, unlink and more. In essence you can create a virtual filesystem in your applications.

Why create custom stream wrappers?

So why in the world would you want to create custom stream wrappers? Basically it comes down to decoupling filesystem-coupled interfaces from the filesystem (or any stream, for that matter). That is, make software think it's talking to files when it's talking to your custom PHP class. It's all about abstraction!

You could also use stream wrappers to simplify an interface, though this is less common. If you are using stream wrappers to simplify an interface, you can just as easily create a normal facade to simplify the interface and leave streams out of it.

For example

I wanted to use a newish PHP templating engine called Dwoo for an upcoming project. The problem was it expects files everywhere. Template files were read from the filesystem and compiled to the filesystem, and caches were written to the filesystem. There was no easy way to change this.

For this particular project I need to read templates from a string (loaded from an arbitrary source decided at runtime), and I can't use the filesystem for caches, I need to use memcached. The reason being that the application will be run in a cluster. Using shared disks is not practical with this many machines, and disk IO would eventually become a bottleneck. True, we could use RAM disks, but it's a lot easier and portable to manage the data layer from our application instead of pushing it to the OS.

Using custom stream wrappers I created two new schemes for 'tpl://' (for reading) and 'tplc://' (for writing compiled templates). I was able to fill the requirements for the project while still using the awesome templating engine with little modification. The library still thinks it's reading and writing to files but behind the scenes it's reading from a cache of template sources and writing to memcached. Perfect!

Creating custom stream wrappers

To create your own custom stream wrappers you need to write a class that implements a set of methods. After you write the class, you can register it with stream_wrapper_register. Refer to that manual page for details on the methods you need.

The only problem I encountered was how to get my custom stream working with is_readable() and is_writable(). The trick is to implement the 'url_stat' method and set the 'mode' correctly. The mode is a number that represents what type of file the file is (file or directory etc) and the file permissions -- the usual chmod values. Here's a code snippet that accurately defines how the number should add up:

$dir = 040000;
$file = 0100000;

// Now you can add any permissions you want using the usual chmod octal notation:
$file += 0777; // A file that is readable
$dir += 0222; // A directory that is writable

The solution that I came up with was to use Flash. Seeing as how over 98% of all users have Flash installed, it was the perfect solution.

I ended up finding an open source project called Sound Manager. You just embed the Flash movie on your page somewhere, and talk to it with plain old Javascript. You don't need Flash installed, you don't need to create your own movie -- all you do is use the API provided by Sound Manager.

For the curious ones amongst you, the API is really simple (taken directly from the linked page above):

soundManager.createSound('myNewSound','/path/to/some.mp3');

soundManager.play('myNewSound');
soundManager.setVolume('myNewSound',50);
soundManager.setPan('myNewSound',-100);

The only problem I had with using Sound Manager is that it requires MP3's, and all of our sounds were WAV's. No biggie. Converting the files to MP3's was simple, and the resulting filesize a bit smaller anyway.

Even more accessible?

98% of internet users have Flash. That's a pretty good percentage. But I still wanted to make sure those rare 2% of users didn't get some "install this plugin" popup.

Basically what I ended up doing was using a Flash sniffer (some JS to determine if Flash is installed, and which version) to see if the user can use the Sound Manager. If they could use it, then great -- we're all set to go. If they couldn't, then the app reverts back to using good ol'd <embed>'s (except for IE7; no sound is better then an annoying security popup!).

The easiest way I've found to do this is with Javascript. It's dreadfully simple code. Here's a sample of what I usually put at the footer of my pages that uses Javascript and PHP:

<!-- All of your HTML here -->

<?php if($do_dst_check): ?>
	<script type="text/javascript">
	var timezone = <?php echo $timezone + $dst_offset; ?>;
	var utc = new Date().getTimezoneOffset() / 60;
	if (Math.abs(timezone + utc) == 1) {
		$.ajax({
			type: 'GET',
			url: 'ajax_update_dst.php',
			success: function() { location.reload(); }
		});
	}
	</script>
<?php endif; ?>

</body>
</html>

How It Works

First you get the time offset that the user has entered into your application, the one you have on record. You need to get the timezone selection and then the current DST offset. For example, if DST is "on" then that just means you +1 to the users selected timezone.

Javascript has something your server-side scripts might not: it knows about the users locale. So using this fact, we can get the users current timezone offset. This is the "real" offset, the one we know is correct, regardless of what they inputted into your application.

Finally, you simply add the offset your application has on record with the users "real" offset. If the result is exactly -1 or 1 (here I used Math.abs, so -1 becomes 1), that means the information you have on record is incorrect, and the DST status needs to be toggled.

In this example I use a jQuery AJAX call to request a page that would toggle the users DST setting.

There is no formal way to actually define member visibility in Javascript (no "public" and "private" keywords like you might see in Java). Instead we just use the language features in such a way that it creates the same public/private situation as we'd expect in other languages (or nearly the same).

Public

A member is public if "the world" can access it. For methods this means anyone can call on it, and for properties this means anyone can use its value or change it. If you are creating object-oriented programs, having nothing but public members breaks a lot of the ideology. In many languages, like PHP before version 5, programmers used conventions to denote members were private and not to be used. Sometimes this works, but true encapsulation is much better.

There are two ways you create public members:

Constructor

function Person() {
    this.name = 'Christopher';
}

var me = new Person();
alert(me.name);

Using 'this' binds the variable to the object, so anyone can use it.

Prototype

function Person() {

}

Person.prototype.name = 'Christopher';

var me = new Person();
alert(me.name);

Adding a method or property to the prototype also makes it public.

Private

A member is private if only the object itself can access it.

To create private members, you define them within the constructor:

function Person() {
    var first_name = 'Christopher';
    var last_name = 'Nadeau';

    function fullname() {
        return first_name + ' ' + last_name;
    }
}

var me = new Person();
alert(me.name); // can't do it!

In this example there are two private properties for first and last name, and one private method to return a full name.

Some Issues...

There are a couple of issues you have to be aware of when using private members.

Only methods defined in the constructor can use private members. That is to say, we cannot do something like this:

function Person() {
    var first_name = 'Christopher';
    var last_name = 'Nadeau';

    function fullname() {
        return first_name + ' ' + last_name;
    }
}

Person.prototype.alertName = function() {
    // Can't do this. 'this.first_name' does not actually exist!
    alert(this.first_name);
}

The scope of the private members are in the constructor only. To get around this problem, you must use what is called privileged methods.

Privileged

As stated before, only methods defined within the constructor have access to private members. Given that many objects are built around using 'prototype', this is problematic. The solution is to create privileged methods.

A privileged method is a method defined in the constructor but assigned to a public variable. Since it is defined within the scope of any other private members, it has access to them. Here's an example:

function Person() {
    var first_name = 'Christopher';
    var last_name = 'Nadeau';

    function fullname() {
        return first_name + ' ' + last_name;
    }

    this.alertName = function() {
        alert(first_name);
    }
}

You can guess that you will be able to retrieve the 'alertName' method or reset it. You might think that it would be possible to redefine the method to take control of some other private member. Not so! The method is a closure and retains the scope in which it was defined. Since it was defined in the scope of the other private members, it has access to them. There is no way to recreate this scope, so even reassigning a completely new function will not allow you to expose any private members.

The 'this' reference

Another thing to be aware of is that functions defined within the constructor have "this" pointing to themselves, and not the object itself. Thus if you need to call other public methods, you cannot. For example, let's make the fullname() method privileged and modify alertName() to call it:

function Person() {
    var first_name = 'Christopher';
    var last_name = 'Nadeau';

    // This is now a privileged method
    this.fullname = function() {
        return first_name + ' ' + last_name;
    }

    this.alertName = function() {
        alert(this.fullname()); // wont work
    }
}

To get around this problem, Javascript programmers assign another private property with the value of 'this' inside the constructor, and use that variable as a reference to the object. The two most common names are 'self' and 'that'; I prefer to use 'self'. Here is the final object, working as expected:

function Person() {
    var first_name = 'Christopher';
    var last_name = 'Nadeau';

    // Create a reference to this object so closures
    // can access it.
    var self = this;

    this.fullname = function() {
        return first_name + ' ' + last_name;
    }

    this.alertName = function() {
        alert(self.fullname()); // Using self to reference the object
    }
}