Wand

API documentation
Overview and Usage
Internals

Introduction

Wand is a password database, integrated in form submit to capture form data and able to fill forms with stored data. It would not be impossible to use it as a generic form data database but it's not used that way today.

Wand will keep passwords in memory and on disk encrypted or obfuscated. To encrypt it, master password must be enabled in general and for wand, otherwise a dummy hardcoded password will be used, and there are already programs (unwand) that has reverse engineered the code and can un-obfuscate the wand database.

When master password is used, many operations require asking the user for that password, which means that many operations in wand can't be performed directly. Instead operations will start but not finish until later. That means that any code using the wand api must be prepared for an async behaviour. This is new for gandalf_3 (core-2.1/2008). Previously the master password dialog had to be synchronous which caused lots of problems.

1. Used OOM policies, Who is handling OOM? and Description of flow

This module uses OP_STATUS where something can fail.
In the function ReportAction that the wandlistener (UI dialog) run, window->RaiseCondition is called if OOM occurs. (Since UI-folks usually don't want to care about checking OP_STATUS)

2. Heap memory usage

There is encrypted data stored for each value that is stored. Proportional to the number of forms and pages that is stored.

3. Stack memory usage

Low. There is some recursive functions but they don't recurse much.

4. Memory ownership

All memory allocated in the wandmodule should be deleted by the wand module.

5. Static memory usage

A defaultimplementation of WandListener. (Just a empty null-implementation).
A couple of variables for initiated status, and storage of a obfuscationpassword.

6. Caching and freeing memory

The data is loaded from file into memory during startup of opera. It is keept in memory until opera exits or the user clears/removes info manually through the UI.

7. Temp buffers

No tempbuffer is used.

8. Memory tuning

No tuning possible. But disabling the ECommerce support will reduce the memory usage a little

9. Tests

The current test checks for memoryleakage by creating a wandmanager, opening a file and closing it, as well as performing some common operations.

10. Coverage

Coverage is probably full. Wand contains quite little code and i'm pretty sure everything is needed.

There is no automatically way to test coverage.