I am working on approach number 2 above. We have version 6.4 of the device, and it provides JSON for a suggestion (possibly new from Riley's question). For instance:
http://code.google.com/apis/searchappliance/documentation/64/xml_reference.html#RichOutputFormat
What I came across is that cross-domain restrictions prevented the use of the JSON service of the device on non-standard forms of website searches, including subdomains of our common high-level domain.
I am testing a simple Java servlet that now invokes a call. It accepts incoming requests, receives a response from the device, displays it in JSONP, and sends it back to the calling page.
There are a few links I found related to proxying the hint service:
http://groups.google.com/group/Google-Search-Appliance-Help/browse_thread/thread/72406a271a6d9917/
http://www.mcplusa.com/blog/2009/07/adding-google-search-appliance-suggest-search-to-your-existing-page/
http://sites.google.com/site/lightbends/gsa_qs_6_2
and some are related to JSONP with jQuery:
http://devlog.info/2010/03/10/cross-domain-ajax/
http://www.ibm.com/developerworks/library/wa-aj-jsonp1/
JSON for JSONP in the servlet is fast and probably messy in the approach I take :)
This is not yet in production, so I canβt talk about what we will find in terms of productivity and other problems. I like that the service is provided from a secondary server, and not directly from the device (taking into account throttling of incoming requests, if necessary, etc.), If the performance can keep up.
October 1, 2010 Update
Sorry - my message above only refers to the service offered, and not to general search results. You can still take the XML response, process it and wrap it in JSON / JSONP, but it will take longer than I suspect. I used JSONP in the context of suggesting search queries with jQuery autocomplete, so it is important to have a quick response (by type).