An odd story caught my attention recently, and I've been meaning to put my thoughts down.

I'm often asked the question about indexing flash content recently, and the recent announcement by google only increased the stir.

It's odd, because even Adobe employees seem completely clueless about what it means, and the implications.

Quote from Ryan Steward:

So what does that mean? We are giving a special, search-engine optimized Flash Player to Yahoo and Google which is going to help them crawl through every bit of your SWF file. This Flash Player will act just like a person would in some cases. It will click on your buttons, it will move through the states of your application, get data from the server when your application normally would, and it will capture all of the text and data that you’ve got inside of your Flash-based application. We’ve basically provided a very powerful looking glass into SWF files so Google and Yahoo can pull out meaningful information.

Is in sharp contrast with what google is saying:

We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an html file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.

So essentially, google will index your SWF, but not the actual content it loads. Most modern Flash Apps don't hardcode any textual content these days, and will likely load most of their data from the servers. Most importantly, I feel the SWF should not be indexed at all. SWF is middleware, it is responsible for delivering content to the user, it (should not) be the actual content itself, for any serious web application.

One more gem from the Google blogposting:

That said, you should be aware that Google is now able to see the text that appears to visitors of your website. If you prefer Google to ignore your less informative content, such as a "copyright" or "loading" message, consider replacing the text within an image, which will make it effectively invisible to us.

So where is this coming from?

My guess is one argument between picking html vs. Flash to deliver your content, it could be said that a Flash is not SEO-friendly. Getting this message out allows pro-flash people to fight back a little. It definitely feels that this whole announcement has little to do with the technology, but much more with putting the Flash-brand in a better light.

How would one actually make SWF's SEO-friendly?

Just don't. Make sure the content is available on the web in an alternative format. Often your flash content is stored in a database (or an XML file for smaller sites). Pick up your favorite server-side scripting language, and make sure the content is also available in an indexable format. Using fancy CSS and Javascript usage you can make sure the content is replaced by the Flash content when a regular user visits.

If you do this, all the normal SEO rules are applied. As a side effect, the user also benefits from this as your content degrades nicely for older or for example mobile browsers, people with disabilities and you name it. The sole reason for this is that search engines are actually try to find 'quality content' based on your search query.

Last but not least, Xhtml is a form of XML. If you use Xhtml as a datasource for your content, search engines can also access it directly.

For future reference, it’s the preference table, record 0 and where the agency_id = 0.  Imagine, who ever would have thought of a password as a preference.  I suppose it’s getting better, in phpAdsNew it was in the config table!

This is where logical thinking can cause you to waste hours of time: an application has many users, each user has a password …

Scavenge the NEWS file, test your apps against current 5.3 CVS. Do whatever it takes to find all the places where PHP 5.3 adds functionality and more importantly where it breaks existing functionality. Let the php-doc team know your findings, post comments on this blog, send me an email or write them directly into the wiki page. If you have a cvs.php.net account, you are already setup. If not then just register yourself and I will grant the necessary permissions. Please please .. help out in this critical effort. Together we can make sure that everybody has all the information to make a painless transition to this feature filed release.

So, I am working on MemProxy some.  Mainly, I am trying to implement more of the Cache-Control header’s many options.  The one that has me a bit perplexed s-maxage.  Particularly when combined with max-age.

s-maxage is the maximum time in seconds an item should remain in a shared cache.  So, if s-maxage is set by the application server, my proxy should keep it for that amount of time at the most.  Up until now, I have just been looking at max-age.  But, s-maxage is the proper one for a proxy to use if it is present.  I do not send the s-maxage through because this is a reverse proxy and, IMO, that is proper behavior for an application accelerating proxy.  However, I do send forward the max-age value that is set by the application servers.  If no max-age is set, I send a default as defined in the script.  Also, if no-cache or no-store is set, I send those and a max-age of 0.

My problem arises when max-age is less than s-maxage.  Up until now, I have sent a max-age back to the client that represents the time left for the cached item in my proxy’s cache.  So, if the app server sent back max-age=300 and a request comes in and the cache is found and the cache was created 100 seconds ago, I send max-age-200 back to the client.  But, I was only using max-age before.  Now, in cases where s-maxage is longer than max-age, I would come up with negative numbers.  That is not cool.  The easiest solution would be to always send the original max-age back to the client.  But, that seems kind of lame.

So, my question is, if you are using an application (HTTP or otherwise) accelerator, what would you expect?  If you application set a max-age of 300 would you always expect the end client to receive a max-age of 300?  Or should it count down over time?  The only experience I have is a CDN.  If you watch CDN traffic, the max-age gets smaller and smaller over time until it hits 0.  I have not tried sending an s-maxage to my CDN.  I don’t know what they would do with that.  Maybe that is a good test.

UPDATE: Writing this gave me an idea.  If the item will be in the proxy cache longer than the max-age ttl, send the full max-age ttl.  Otherwise, send the time left in the proxy cache.  Thoughts on that?

(thanks for being my teddy bear blogosphere)

I have tried to write a custom coding standard for PHP_CodeSniffer. The documentation shows you how to do this when the coding standard ist located in the PEAR directory.

I don't want to put the standard into the PEAR directory, because I need more flexibility. Some projects may have stricter or more relaxed standards, and I'm also working towards using phpUnderControl together with CruiseControl, so I'd prefer to keep the coding standard in subversion.