One possible direction forward here would be to start by offering a configurable option to let Field Search sit over a GSearch instance for a given repository (or pool of repositories). The API that Field Search offers could be translated to calls against GSearch's API, if institutions that choose this path can be sure to include in their indexing everything necessary to support Field Search, or if we could devise a "graceful collapse" of the Field Search query protocol to allow for situations in which some fields are not indexed and cannot be searched.
--- A. Soroka Online Library Environment the University of Virginia Library On Jun 17, 2011, at 8:59 AM, Chris Wilper wrote: > On Fri, Jun 17, 2011 at 4:39 AM, Gert Schmeltz Pedersen > <[email protected]> wrote: >> If you move FieldSearch out of core, I am curious to know, what FieldSearch >> can do, that GSearch cannot do? > > I don't know of anything that FieldSearch does that GSearch (or more > accurately, any of its underlying search technology options) cannot. > It seems to me that the only reason we might want to keep FieldSearch > functionality at all is for people/applications that have become > dependent on it and would find it difficult to upgrade without it. > Then the natural question is "for how long?" ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
