[Building Sakai] Search help

[Adrian Fish]

I've modified SRCH-89 to depend  on KNL-936 and repurposed it as a legacy
search api facade. When you've got something in place I can help out
switching the EntityContentProducers that you mention across.

Cheers,
Adrian.

On 23 June 2012 14:46, Aaron Zeckoski <azeckoski at unicon.net> wrote:

> Last I checked it was:
> Announcements
> Assignments
> Email Archive
> Chat
> Message Center
> Resources
> Sites (via site-manage)
> Users
> Wiki
>
>
> All of those are core so I would say we just switch them over from
> EntityContentProducer (the old registration API) to the new search
> registration API for content (which will not depend on or connect to
> the legacy entity API). It should actually be a lot easier and I plan
> to link it to EB as well so it should be possible to make entities
> searchable with little effort (in theory - this is a nice to have).
>
> -AZ
>
>
> On Sat, Jun 23, 2012 at 8:46 AM, Adrian Fish <adrian.r.fish at gmail.com>
> wrote:
> > Are there really that few tools using the current apis? If that's so,
> then
> > great, a re envisioning of the apis should be done. We should have an
> idea
> > though of how many tools do use the current apis; if it's good few then
> > we'll still have to maintain the current api, maybe as a legacy layer
> that
> > we can dump later on. A legacy lib will also still be a good idea if a
> tool
> > wants to run on old kernels without branching.
> >
> > Perhaps modify SRCH-89 so it becomes a proxy onto the new interface
> coming
> > out of KNL-936? Everything still works then, in theory.
> >
> > Cheers again,
> > Adrian.
> >
> >
> > On 23 June 2012 13:32, Aaron Zeckoski <azeckoski at unicon.net> wrote:
> >>
> >> The APIs will be in kernel for sure since search needs to be a core
> >> part of the system (IMO).
> >> The impls though... probably not. And you are on the right track but I
> >> think we need to replace the current search APIs as part of this
> >> effort. Implementing under the current ones would be very difficult
> >> and considering the small number of things actually using the current
> >> APIs it is easier to remake the APIs and reimplement than to try
> >> shoehorn solr and elastisearch under them.
> >>
> >> :-)
> >> -AZ
> >>
> >>
> >> On Sat, Jun 23, 2012 at 8:18 AM, Adrian Fish <adrian.r.fish at gmail.com>
> >> wrote:
> >> > This is the proxy JIRA that I'm on with ...
> >> >
> >> > https://jira.sakaiproject.org/browse/SRCH-89
> >> >
> >> > The main idea was to be able to transparently support the current
> search
> >> > whilst incorporating Oxford's SOLR work and opening the door for an
> >> > elasticsearch implementation. I just assumed I'd be doing that to get
> >> > the
> >> > Oxford stuff in and switchable.
> >> >
> >> > You must be doing this one:
> >> > https://jira.sakaiproject.org/browse/KNL-936.
> >> > I'm happy dropping the one I'm doing, especially seeing as I can't get
> >> > the
> >> > components to wire together :)
> >> >
> >> > Why is it being done in kernel though? Is search being moved in there?
> >> >
> >> > Cheers,
> >> > Adrian.
> >> >
> >> >
> >> > On 22 June 2012 18:02, Aaron Zeckoski <azeckoski at gmail.com> wrote:
> >> >>
> >> >> Sounds like you might be duplicating work I am doing. What jira are
> you
> >> >> working under? Can you link to the ones outlined in the TCC 2.10
> >> >> confluence
> >> >> page?
> >> >>
> >> >> On Jun 22, 2012 12:16 PM, "Adrian Fish" <adrian.r.fish at gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> I'm trying to slip in a searchservice proxy which just delegates to
> >> >>> the
> >> >>> 'real' search service, currently the ConcurrentSearchServiceImpl. My
> >> >>> bean's
> >> >>> init method just isn't getting called and I reckon it's some kind of
> >> >>> circular dependency.
> >> >>>
> >> >>> Does anybody know of any docs about how the various search spring
> >> >>> components wire together?
> >> >>>
> >> >>> Cheers,
> >> >>> Adrian.
> >> >>>
> >> >>> _______________________________________________
> >> >>> sakai-dev mailing list
> >> >>> sakai-dev at collab.sakaiproject.org
> >> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >> >>>
> >> >>> TO UNSUBSCRIBE: send email to
> >> >>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> >> >>> "unsubscribe"
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> >
> >
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20120625/df3754e0/attachment.html