Previous solutions for a searchable SWF were workarounds using swf2html or attaching xml to a page. Adobe and Google have worked together to make SWFs show up in Google results.
A special version of the Flash Search Player (Ichabod) steps through visual states and gets the text. It only finds text fields that would actually be shown in the display list. Ichabod must be fast, so it executes faster than real time and doesn’t render. Since it must be deterministic, there’s no network access, sockets, or threads (sound). Thinking about providing a version of Icabod that’s available to everyone to allow you to search SWFs yourself.
If you load in any external media, this currently won’t be used within the SWF. But Adobe has fixed their side of this issue, and it just needs some work from Google to work correctly. It’s expected that when Loader.load() is used, Google will fetch or get a cached version of the call. An example of this from the Adobe side was used with the Flex store.
What’s next, in no particular order:
1. Dealing with external media, as mentioned above.
2. Deep linking. It doesn’t currently deal with unique URLs for different states in a SWF, but they’re trying hard to get this done.
3. Partner with Yahoo and other search engines.
4. Getting accessibility text.
5. Thinking about getting metadata from progressive download videos, especially with the work at Adobe for getting text from video.
It’s possible to use Ichabod for unit tests if this player gets released. It could be extremely helpful for this, since the tests would run much quicker.
The questions at the end turned into a session on how to try to thwart the system. I’m not going to post the suggestions that came out of it, but it was pretty creative.