Since ports below 1024 require root permissions in order for processes to use them on OS X, and I didn't want to run some other server process just to serve policy files, I needed to kludge a way to send the policy file from my nice, elegant socket server every time a client connected and requested a policy file. The example below is a simplified version, as it only listens on one port - the project I was working on was basically a proxy from one SWF to another, so I had two socket servers that needed to listen for the requests for a policy file and respond. In this example, the server listens for connections on port 5208, and simply echoes incoming data from the client to System.out, and has some visual feedback in the window. When the incoming message contains the string "policy-file-request" (the entire message from Flash will be terminated with a null char), we simply spit back the XML for a wide-open socket policy, followed by a null char (This is required, or the Flash player will not accept the policy file. This is what tied me in knots last night. RTFM!)

import processing.net.*;

int bgLevel = 0;
int port = 5208;
Server server;

String flashDomainPolicy = "<?xml version=\"1.0\"?>"
                              +"<cross-domain-policy xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:noNamespaceSchemaLocation=\"http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd\">"
                              +"<allow-access-from domain=\"*\" to-ports=\"*\" secure=\"false\" />"
                              +"<site-control permitted-cross-domain-policies=\"all\" />"
                              +"</cross-domain-policy>";

void setup ()
{
  size(200, 200);
  server = new Server(this, port);
  background(bgLevel);
}

void draw ()
{
  Client client = server.available();

  if (client !=null)
  {
    String message = trim(client.readString());

    if (message != null)
    {
      if (match(message,"policy-file-request") != null)
      {
        sendFlashPolicy(server);
      }
      else
      {
        server.write(message);
        System.out.println(message);

        // Change the background color to indicate message activity
        bgLevel = 255;
      }
    }
  }

  // Fade to black
  if (bgLevel>1)
  {
    bgLevel-=2;
    background(bgLevel);
  }
}

void sendFlashPolicy(Server socketServer)
{
    socketServer.write(flashDomainPolicy+char(0));
    System.out.println("Sending Flash policy file");
}

You can test this without a Flash client by firing up the sketch and telnetting to the port. Any strings you send will be echoed to System.out, unless you send the string "policy-file-request" in your message, which will result in the server sending the policy XML to you. You should be able to connect a Flash client to this server and start communicating right away.

ClipStation is designed to be lightweight, flexible, and easy to implement. What makes ClipStation different from other clipboard SWF solutions is the ability to decode HTML character entities, allowing you to pass complex HTML markup to the clipboard from within form elements, divs, pre tags, etc. We developed ClipStation for use on a widget sharing page we've implemented for a client. After looking around for a good lightweight cross-browser solution and coming up empty handed, we decided to build our own. We're now happy to offer it to you at the low, low price of free.

Version 2.0 includes changes to allow access to the clipboard in Flash Player 10. Adobe changed the security requirements for clipboard access in version 10 of the player; now a user action is required before a SWF may access the clipboard. Instead of using a single hidden instance of the ClipStation SWF, we embed an instance for every clip that the user clicks to perform the clipboard copy. A source distribution is available, so you can change the design to fit your needs.

More information and the release package can be found at thirdpartylabs.com/clipstation/

»Download ClipStation 2.0

"We were looking at SWF Address a while ago. While it’s very cool it was useless for what we wanted. By using HTML anchors (# in the URL) the deep links are only relevant to client side logic inside the browser (JavaScript, HTML and Flash).

If you serve HTML content generated server side, in addition to flash there is no way to extract the deep link from the URL (after the #) as it’s not passed to the server in the request!

I will be interested to see if they have updated this in the new version… and also see what changes have been made to SWFObject2, or swffix or whatever it’s called these days."

I had to read that twice.

SWFAddress is not a solution for implementing multiple content types. It's purpose in life is to keep the browser informed about the user's movements within a rich application. It does that job very well. One of the things you can do with SWFAddress is implement your own solution for managing your URLs across multiple content types.

Jon and I are just finishing up a big client site for which we have a nifty flash client and an SEO/Usability optimized HTML version of all content on the site. SWFAddress allowed us to maintain a similar URI structure for both, and a little bit of custom javascript handles the translation of SWFAddress URIs, which all start with # to the standard URIs, and vice-versa. SWFObject handles the embedding of the Flash client. It's a really simple solution that took less than an afternoon to prototype and refine into a production-ready solution. I'm not saying this to make myself out to be a bad-ass, it's just not rocket science. All it takes is a general understanding of how the tools work, and the willingness to craft your own solutions to your specific problems.

There are well built, elegant, open source libraries to do just about anything these days. The thing is, they're libraries, tools, not complete solutions. They will solve the tough 80% of your problem for you. It's up to you to do the last 20% and make the tool work for you. Enter the 80/20 rule, or, more specifically, the 2080 concept.

The 20 missing percent of functionality will take up 80% of the build time.

If you expect canned solutions to solve your problems 100%, you will constantly be disappointed, and, most likely, be building poor software. If you go into your project knowing that a tool you will rely on provides a limited set of functionality, and you will need to do devote time and energy to make it fit, you will be more likely to succeed.

"There is something to be learned from a rainstorm. When meeting with a sudden shower, you try not to get wet and run quickly along the road. But doing such things as passing under the eaves of houses, you still get wet. When you are resolved from the beginning, you will not be perplexed, though you still get the same soaking. This understanding extends to everything."

-Yamamoto Tsunemoto, Hagakure