[Building Sakai] Search help

[Adrian Fish]

I'm all for a simplification of the searchable API.It would be nice to just
have an interface called SearchIndexable that gets picked up during the
enitityprovider registration. No more explicit registration of content
producers.

We should still probably leave the old interface there in some form though;
there are surely contrib tools that use it. COG and YAFT do although I
could change those. What I don't particularly want, though, is to have to
branch versions just to target different search interfaces when we could
offer a facade of some sort. I may well be getting the wrong end of the
stick here, if so, tell me, I can take it.

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/20120623/491355a5/attachment.html