[Building Sakai] Search help

Sun Jun 24 03:59:56 PDT 2012

Go ahead and add a comment to that ticket and we can consider this
along with the other stuff.
https://jira.sakaiproject.org/browse/KNL-936
Thanks
-AZ


On Sun, Jun 24, 2012 at 12:08 AM, Colin Hebert
<colin.hebert at oucs.ox.ac.uk> wrote:
> I'm currently working on a new SearchAPI
> (https://github.com/ColinHebert/Sakai-Search2).
>
> This is still a work in progress, (I forgot to push a few commits) but
> I ended up with a backward compatible implementation (not yet pushed),
> meaning that you can use an implementation for the current search API
> and wrap it for the new API, or you can use a ContentProvider of the
> current API with the new API without having to change anything.
> It's still relying on ContentProducers though (but a new kind of
> ContentProducer *), mostly because it allows the API to be independent
> from EntityBroker, but if you think that's a better way to deal with
> Content generation it could (should) be easily integrated.
>
> *Actually, it now relies on two different things, IndexEventHandlers
> (I'm not good at finding nice names for classes) which are used to
> handle any triggered event which could affect the index (new content,
> deleted content, site deleted, tool disabled on a site, tool reenabled
> on a site, ...), and ContentProducers which will provide the actual
> content (and metadata).
>
> In most cases, the IndexEventHandler will depend on a ContentProducer
> (new file added to content-tool, the ContentToolIndexEventHandler
> would then need to extract the content with the
> ContentToolContentProducer), but sometimes it just doesn't need one
> (SiteIndexEventHandler which will remove everything related to one
> site from the index if the site is "disabled" [the content is still
> here, but not accessible so it shouldn't be searchable], and it would
> reindex the site if this one is re-enabled [because the content is
> still here, but not indexed anymore]).
>
> For me it made more sense to have two different components for those
> two different tasks.
>
> Cheers,
>
> Colin
>
> On Sat, Jun 23, 2012 at 10:14 PM, Adrian Fish <adrian.r.fish at gmail.com> wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> 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