Searchmanager module

Copyright © 2004-2008 Opera Software ASA. All rights reserved. This file is part of the Opera web browser. It may not be distributed under any circumstances.
$Id$

Introduction

The searchmanager module contains functionality for storing and loading URLs to different searchengines and given a search query produce an URL to that searchengine with that query. It also supports giving each searchengine a nickname. For example the string "g foo" could become "http://www.google.com/search?client=opera&rls=en&q=foo&sourceid=opera&num=10&ie=utf-8&oe=utf-8".

The searchengines are stored in the file search.ini. Format for a searchengine is:

[Google]
ID=1
Version=0
Deleted=0
Is Separator=0
GUID=
Name ID=17171
Name=
Description ID=0
Description=
URL=http://www.google.com/search?q=%s&sourceid=opera&num=%i&ie=utf-8&oe=utf-8
Key=g
Is post=0
Post Query=
Type=1
Icon URL=
Encoding=utf-8
where %s in the URL value means that the search query should be placed there and %i means that the preferred number of answers per page should be placed there. This number is controlled by the preference PrefsCollectionCore::PreferredNumberOfHits.

Use cases

Find search string if you want to search for "foobar" on google (post_query will be empty if google search is not using POST) :

//Find search element by key ('g' for Google). Can also be done by ID or URL
SearchElement* search_element = g_search_manager->GetSearchByKey(UNI_L("g")); 
if (search_element)
{
	OpString search_query;
	OpString post_query;
	if (OpStatus::IsSuccess(search_element->MakeSearchString(search_query, post_query, UNI_L("foobar"))))
	{
		...
	}
}

API documentation

For detailed information on how to use the style module in Opera and the module's public API, please refer to the API documentation.

Memory documentation

Used OOM policies

Searchmanager will usually return OP_STATUS, except for functions calling lots of functions that LEAVE, where the functions in searchmanager also will Leave (to avoid lots of TRAPs). For example the function SearchManager::LoadL.

Who is handling OOM?

OOM situations is handled by the caller.

Description of flow

The file search.ini is read using PrefsFile and an object for each searchengine is stored in memory. If searchengines are modified or new searchengines are added this is written back to the file.

Heap memory usage

There is one SearchElement object per searchengine.

Stack memory usage

There are no recursive functions.

Static memory usage

There is a global SearchManager object.

Caching and freeing memory

Only needed allocated memory is kept

Freeing memory on exit

Memory is freed in SearchmanagerModule::Destroy, called when terminating Opera.

Temp buffers

Temp buffers are not used.

Memory tuning

module.export let you run a stripped-down version of searches (reducing object size for objects kept in the list in memory).

Tests

Coverage

Design choices

Suggestions of improvements

Module implementation

The code is supposed to meet all requirements from platform teams, while being simple to use. Just initialize it with the read-only opera-provided search.ini, and a writable file for user-defined searches in case user-defined searches are module.import'ed. When it is initialized, you can query, iterate, add, remove and modify searches, as well as giving URL to an OpenSearch (www.opensearch.org) XML file the user wants to add (it will be downloaded and added async, sending a message to the global messagehandler when done). You can force a writing of the user-defined search.ini (if not, it will be done at shutdown, if needed). Everything else is pretty much handled for you.