OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (CMIS-86) Provide a new servicethat will allow search crawlers to efficiently navigate a CMIS repository.



    [ http://tools.oasis-open.org/issues/browse/CMIS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10142#action_10142 ] 

Gregory Melahn commented on CMIS-86:
------------------------------------

David, we had thought about the idea of allowing input scopes to include folders, but decided to keep it simpler for the providers.   The client could to do the scoping by using getObjectParents.   I agree it would be easier on the clients if the entries already had the path(s) but we did not talk about including the paths in the entries and I would be curious in the opinions of the ecm providers on whether that would be something that could be done with decent performance.  But for the client to index based on scope would mean the client has to then also worrry about whether the filing operations would be treated as content changes (which is stated in the proposal to be a repository choice).   

> Provide a new service that will allow search crawlers to efficiently navigate a CMIS repository.
> ------------------------------------------------------------------------------------------------
>
>                 Key: CMIS-86
>                 URL: http://tools.oasis-open.org/issues/browse/CMIS-86
>             Project: OASIS Content Management Interoperability Services TC
>          Issue Type: New Feature
>          Components: Domain Model, REST/AtomPub Binding, Schema, Web Services Binding
>    Affects Versions: Draft 0.50
>            Reporter: Gregory Melahn
>            Assignee: Ethan Gur-esh
>             Fix For: Draft 0.6
>
>
> CMIS needs to allow repositories to expose what information inside the repository has changed in an efficient manner for applications of interest, like search crawlers, to facilitate incremental indexing of a repository.
> In theory, a search crawler could index the content of a CMIS repository by using the navigation mechanisms already defined as part of the proposed specification. For example, a crawler engine could start at the root collection and, using the REST bindings, progressively navigate through the folders, get the document content and metadata, and index that content. It could use the CMIS date/time stamps to more efficiently do this by querying for documents modified since the last crawl.
> But there are problems with this approach. First, there is no mechanism for knowing what has been deleted from the repository, so the indexed content would contain 'dead' references. Second, there is no standard way to get the access control information needed to filter the search results so the search consumer only sees the content (s)he is supposed to see. Third, each indexer would solve the crawling of the repository in a different way (for example, one could use query and one could use navigation) causing different performance and scalability characteristics that would be hard to control in such  a system.  Finally, the cost of indexing an entire repository can be prohibitive for large content, or content that changes often, requiring support for incremental crawling and paging results.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]