What you really want, of course, is one or both of these flows: data -> display -> display-oriented search indexer data -> data-oriented search indexer
Google's indexer is display-oriented, so you want to feed it the display form of your data. This is only difficult in Exhibit's case because the display logic is client-side and Google is presumably indexing the HTTP response content (rather than running a virtual browser that executes the page as it would be displayed and then processes the resulting DOM). But moving the display logic to the client is, in fact, Exhibit's genius, because it allows you to reach users who don't have the technical knowledge or access permissions to do server-side manipulations. So any variation that *does* require server-side manipulations, even ones as seemingly simple as putting up a static alternative page, will eliminate much of your target userbase. Actually, even *producing* that static page is tricky. Safari lets you save as Page Source or a Web Archive, but the former doesn't run the Javascript, and the latter is Safari-specific. Firefox gives you an option for "Web Page, complete", which looks promising, but for me reopening the resulting file in either Firefox or Safari produced Javascript errors and didn't display the Exhibit data, either. So I think, unfortunately, that you're kind of stuck. Until Google's indexing gets a generation more sophisticated, your display logic has to live on a server. So if you want to offer display-logic services to people without control of their own servers, you can really only do it by hosting the data and the services on *your* server. That is, you could host a site where people can upload their data and build (and then link to) Exhibits of it. Do for data what Flickr does for photos. But that's a very different project than the one Exhibit was trying to be... glenn _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
