Hi Gert, 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?" > On 16/06/2011, at 23.26, Benjamin Armintor wrote: > I think moving FieldSearch, ResourceIndex, and GSearch (among unknown > others) out of core and into a queue of indexing services is an > admirable development goal. Since GSearch is notified via JMS of Fedora updates, I would consider it architecturally "ahead of" where we're currently at with the Resource Index (ignoring FieldSearch for now). My question is, is a JMS queue the common integration technology that all such external services should be hooked up to in order to integrate? And can they call depend on the same kinds of messages? (a message-per method model as exists today, or a more object-change-oriented model as I think was suggested by Steve at last week's meeting). - Chris ------------------------------------------------------------------------------ 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
