tree: ff7fe39a3826823194f7d0d13ee8ea210e9c7634 [path history] [tgz]
  1. public/
  2. BUILD.gn
  3. content_extraction_utils.cc
  4. content_extraction_utils.h
  5. content_extraction_utils_unittest.cc
  6. DEPS
  7. index.cc
  8. index.h
  9. inverted_index.cc
  10. inverted_index.h
  11. inverted_index_search.cc
  12. inverted_index_search.h
  13. inverted_index_search_unittest.cc
  14. inverted_index_unittest.cc
  15. linear_map_search.cc
  16. linear_map_search.h
  17. linear_map_search_unittest.cc
  18. local_search_service.cc
  19. local_search_service.h
  20. local_search_service_provider_for_testing.cc
  21. local_search_service_provider_for_testing.h
  22. local_search_service_provider_unittest.cc
  23. local_search_service_proxy_unittest.cc
  24. local_search_service_unittest.cc
  25. oop_local_search_service_provider.cc
  26. oop_local_search_service_provider.h
  27. OWNERS
  28. pref_names.cc
  29. pref_names.h
  30. README.md
  31. search_metrics_reporter.cc
  32. search_metrics_reporter.h
  33. search_metrics_reporter_unittest.cc
  34. search_utils.cc
  35. search_utils.h
  36. search_utils_unittest.cc
  37. shared_structs.cc
  38. shared_structs.h
  39. test_utils.cc
  40. test_utils.h
chromeos/components/local_search_service/README.md

Chrome OS Local Search Service

LocalSearchService provides on-device data storage/indexing and flexible search functions via approximate string matching. It supports both in-process and out-of-process clients with the use of a mojo wrapper.

Index

LocalSearchService owns one or more Index's, which implement data indexing and search. A client can request to have its own Index. Before a client can start using its Index, we will need to add a new IndexId that will be used by the client as a key when requesting an Index via LocalSearchService::GetIndex.

Supported backends

An Index could use one of the two backends for storage/indexing and search: linear map (Backend::kLinearMap) and inverted index (Backend::kInvertedIndex). A client can specify which backend to use by adding a Backend parameter to LocalSearchService::GetIndex. This is an optional parameter and defaults to Backend::kLinearMap if not specified.

If a client's corpus is relatively small, e.g. hundreds of documents and each document contains a few keywords then a linear map should suffice. If the corpus is large and each document is a full article, then an inverted index would be more appropriate: it will parse documents, (optionally) remove stopwords and rank documents via TF-IDF.

Search parameters

A client can configure SearchParams of its Index, but this is not necessary because default parameters have been set to optimal values. We suggest you reach out to us before changing the parameters.

How to use

In-process clients

An Index can be requested as follows

  1. Call LocalSearchServiceFactory::GetForProfile to obtain a LocalSearchService pointer.
  2. Call LocalSearchService::GetIndex via the pointer above to obtain an Index pointer.

Subsequently the client can start adding/updating/deleting data and search. For details, please see index.h for all functions and return results.

Out-of-process clients

If a client is running out-of-process, the client will need to

  1. Set up a remote to mojom::LocalSearchServiceProxy, have the receiving end bound to its implementation via LocalSearchServiceProxyFactory::GetForProfile(profile)->BindReceiver.
  2. Set up a remote to mojom::IndexProxy, have the receiving end bound to its implementation via mojom::LocalSearchServiceProxy::GetIndex.

Functions will be similar to their in-process counterparts, except the calls now will be asynchronous and results will be returned via callbacks. For details, please see proxy/local_search_service_proxy.mojom'