[Building Sakai] Search help

[Aaron Zeckoski]

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