portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Spencer <paulspen...@mindspring.com>
Subject Re: [Proposal] Lucene Search Service
Date Fri, 23 May 2003 01:28:51 GMT
Mark,
Mark Orciuch wrote:

>Paul,
>
>Sorry about the poor phrasing. The portlet registry knows about the sources
>of portal's content and therefore could also be made searchable. As a matter
>a fact, the indexing process can walk through the registry and index all
>files referenced by the url attribute of each portlet entry.
>  
>
See below, but lets keep the "indexing process", i,e, the SearchService, 
separate from the "walk through the registry", i.e. "PortletSearch" 
portlet mentioned below.

>However, one aspect if indexing portal content that bothers me is security.
>So you index every .html file in the portal (just as an example). Each .html
>file is "wrapped" as a portlet and can have access restrictions. How do you
>filter out these from the search results based on the user access rights?
>  
>
Who is "you" in "index every .html file in the portal?"  Document must 
be added to the index, via the SearchService, by another portlet, 
service, or external application.  The "SearchService" is not adding 
"index every .html file in the portal"

>It would be nice to give the user a search result containing links to either
>preview found portlets and/or add them to current pane (or something like
>that).
>  
>
How about the Registry services add each portlet to the index with the 
following fields:
    SecurityRef = the portlet's security ref
    Catalog = PORTLET_ENTRY

The  "PortletSearch" portlet will append "+Catalog:PORTLET_ENTRY" the 
query.  It would then test each portlet to against the user's security. 
 If the user is allowed to view the portlet, then it will be displayed 
to the user.   In short the"PortletSearch"  portlet with the 
SearchServices is responsible for security.  Also "PortletSearch" 
 portlet will format the "preview" link.

>Best regards,
>
>Mark Orciuch - morciuch@apache.org
>Jakarta Jetspeed - Enterprise Portal in Java
>http://jakarta.apache.org/jetspeed/
>
>  
>
>>Mark,
>>
>>What?
>>
>>.xreg file contain descriptive information ABOUT a registry entires,
>>like portlets. They do NOT contain portlet content.  If you want the a
>>portlet's content searchable, then I suggest having the portlet add it's
>>content to the search service, via the add method.
>>
>>Paul Spencer
>>
>>Mark Orciuch wrote:
>>
>>    
>>
>>>I fully support this proposal. One very important document handler that
>>>comes to mind is .xml (.xreg). To me, indexing portlet registry would be
>>>very important because that's where where the portal's content resides. I
>>>wouldn't mind getting involved in this task once we agree on the
>>>architecture.
>>>
>>>Best regards,
>>>
>>>Mark C. Orciuch
>>>Next Generation Solutions, Ltd.
>>>e-Mail: mark_orciuch@ngsltd.com
>>>web: http://www.ngsltd.com
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>I've noticed the new LuceneSearchService and have been giving
>>>>some thought
>>>>as to how I might like to put it to use.  I'll admit to not
>>>>having that much
>>>>experience with Lucene, so if anyone thinks that this won't work,
>>>>just let
>>>>me know.
>>>>
>>>>In terms of the service, perhaps there should be a generic SearchService
>>>>interface of which the Lucene service is an implementation.
>>>>        
>>>>
>>That way, if
>>    
>>
>>>>there was some other great search engine someone wanted to use,
>>>>they could
>>>>swap it out.
>>>>
>>>>I was thinking that there could be 4 basic methods.  These would be
>>>>add(Object o), update(Object o), remove(Object o), and
>>>>        
>>>>
>>search(query).  In
>>    
>>
>>>>order to support more than one object type, we could setup the
>>>>        
>>>>
>>service to
>>    
>>
>>>>accept LuceneDocuement loaders, which would know how to turn the generic
>>>>object into a Lucene document that can be added to the index.  Here's an
>>>>outline.
>>>>
>>>>services.SearchService.classname=org.apache.jetspeed.services.sear
>>>>ch.lucene.LuceneSearchService
>>>>services.SearchService.index=WEB-INF/index
>>>>
>>>>services.SearchService.handler.name=ObjectXHandler
>>>>services.SearchService.handler.ObjectXHandler.classname=com.mycomp
>>>>any.lucene.ObjectXToDocument
>>>>services.SearchService.handler.ObjectXHandler.object_type=com.myco
>>>>mpany.ObjectX
>>>>
>>>>services.SearchService.handler.name=ObjectYHandler
>>>>services.SearchService.handler.ObjectYHandler.classname=com.mycomp
>>>>any.lucene.ObjectYToDocument
>>>>services.SearchService.handler.ObjectYHandler.object_type=com.myco
>>>>mpany.ObjectY
>>>>
>>>>So, when it comes time to add the object to the index, the
>>>>service looks up
>>>>the appropriate object handler, uses it to convert the object
>>>>        
>>>>
>>to a Lucene
>>    
>>
>>>>document, and then adds/updates/removes it from the index.  In terms of
>>>>searching, this would allow all kinds of different indexed
>>>>documents to be
>>>>returned from a search.  Perhaps a filter could be placed in the
>>>>search so
>>>>that only certain types of documents that originally came from
>>>>certain types
>>>>of objects could be returned.
>>>>
>>>>Again, just an idea.  But it strikes me as a powerful one with
>>>>respect to a
>>>>general indexing solution.
>>>>
>>>>Jeremy Ford
>>>>
>>>>_________________________________________________________________
>>>>Protect your PC - get McAfee.com VirusScan Online
>>>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>      
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>    
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>  
>




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message