Re-write module as Search API Plugin

@captiandav, i think that makes boatloads of sense. The original 7.x implementation was a hijack of core search for design patterns. As such, it has limitations. I was thinking along those lines for the 8.x version, but if you are willing to throw some time at this, I (and perhaps a few other regular users of this module) can assist with reviewing and getting it working. Were you thinking 8.x or 7.x?

I'd need to dig in to the Search API, but I have initial reservations. Utmost is: how will indexed content in GSA from outside of Drupal be handled?

I, too, would need to dig a little and figure out how we can provide results. It boils down to third-party integration. My initial thought is there's a lot of duplication between core search and google_appliance, and if there's a way to make it leaner (provide structured data only) then I think it makes sense. I'm working with Search API on another project right now so, i'll think about it while get up to speed with that. Feel free (anyone) to deposit two cents.

It would be great if the Core Search API could be extendable to plugin to different search source datasources as needed.
EG:

Internal Search (Core)
Google Search Appliance
Google Custom Search
AWS CloudSearch
Any other search sources, maybe Solr?

The core search could be more of a framework for working with any search provider, easily extended.

@captaindav, i'd be happy to answer questions and review patches for this. If there is a sensible way to implement as SAPI plugin, i think it makes sense. I'm wondering if it should be a separate project, though? We can't alienate users of the full module. Perhaps at least a 7.x-2.x branch would be best. Thoughts?

@captiandav, I would vote for search_api_google_appliance for clarity. I like the idea of minimizing the D8 port.

There's such a provider being written at one of my customer's sites. I expect it will be submitted rather sooner than later.

Is this d7 or d8?

It is for D7. No work underway for D8 at this time, since this is code targeted for production.

I'm curious about whether this effort ever got underway, and if so, where the current codebase is for it? I don't know how much time I have to help with raw development, but I'd certainly be glad to spend some time doing QA/bug fixes if/when you have some functions or a module to test...

@mausolos, as far as I can tell nothing happened towards this issue.

Yes, the module was released internally around the time I mentioned. I'll double check when/if public release is planned.

@fgm, please do. I'm keen to pull some of that in, if possible.

That being said, based on conversations I've had with Nick Veenhof, I'm not 100% sure how well and to what extent Google Appliance and Search API can be integrated; so much of the API is related to indexing, which is obviously not necessary for GSA.

Any updates from anyone on this thread about this?

Also, just officially linking the aforementioned Search API issue with this...

Forgotten to follow-up here : actually public release has not been approved and likely won't be.

It might well not be reasonable or possible to figure out how to integrate GSA search with Search API. However, there are some specific things I'd like to see from GSA at some point, one way or another.

The level of integration I'd like to see is a bit more collaboration between Drupal and GSA, and that the results coming back are a bit smarter. Is this link an Entity? What kind, a Node? Taxonomy? User? Can I get Display Suite to render the Entities in specific ways? Can I have Views intercept the results so I can do cool things with filters and relationships and blocks? (How cool would it be to have a smart, related search block on certain high-traffic pages that uses the clean URL as a search query? "If you like this article, check out these (with photos and author link)")

These are things we get with SearchAPI, and I think there might be some ways to get this out of GSA as well. For instance, what if we used metadata to indicate the nid or tid or uid, as well as the Entity type and a site-specific identifier? That's really all we need, isn't it?

On the OTHER hand...

At my company, we use GSA as a large area search service. That is, we have many sites being indexed throughout the company, and we're returning results for many of them from on our intranet (the Drupal site). The Drupal intranet site itself is a multi-site beast, and in fact I'm redirecting results from any search form on any of the multi-site sub-sites to the "main" site (the one with the base URL). So even if we did have this higher integration available, it would be almost useless to me except for the Entities that just happen to be on that main site.

So here's something I've done to work around this. I use local SearchAPI indices in conjunction with the GSA. I created a views block with search_api_views that references the user index. Then I can return a result for users with photos and links to the user accounts above the GSA results. I suppose I could add tabs on my search results page that trigger views pages/blocks results of other local index results (maybe a list of hotels, or a calendar, or whatever, YMMV).

Still, I would architect my search pages differently if I knew I could get rich, local results.