MAPIStore 10 backendfolder structure
Version 14 (Julien Kerihuel, 2011-10-13 02:15 pm)
| 1 | 1 | Julien Kerihuel | h1. MAPIStore 1.0 backend.folder structure |
|---|---|---|---|
| 2 | 1 | Julien Kerihuel | |
| 3 | 1 | Julien Kerihuel | h2. folder.open_folder |
| 4 | 1 | Julien Kerihuel | |
| 5 | 2 | Julien Kerihuel | This function opens a folder in the backend. It should only perform an action when the folder is not a root/mapistore folder (referenced in openchange.ldb), since these specific root folders are opened during [[MAPIStore_10_backendbackend_structure#backendcreate_context-function|context creation]] and morphed/returned as a folder object when [[MAPIStore_10_backendcontext_structure#contextget_root_folder|context.get_root_folder]] returns. |
| 6 | 2 | Julien Kerihuel | |
| 7 | 2 | Julien Kerihuel | For any folders within a backend and different from the root folder, the folder should be opened. The function takes in parameter: |
| 8 | 2 | Julien Kerihuel | * _void *parent_folder_: the parent folder object of the folder to open |
| 9 | 4 | Julien Kerihuel | * _TALLOC_CTX *_: the memory context to allocate folder_object with |
| 10 | 2 | Julien Kerihuel | * _uint64_t fid_: the folder identifier of the folder to open |
| 11 | 2 | Julien Kerihuel | * _void **folder_object_: the opened folder object to return |
| 12 | 2 | Julien Kerihuel | |
| 13 | 3 | Julien Kerihuel | Folders are opened within a given context, which folder object is retrieved through [[MAPIStore_10_backendcontext_structure#contextget_root_folder|context.get_root_folder]] call. While this specifically apply to folder underneath the root folder, the same logic apply to sub folders which parent is not the root folder object within the context. It requires either to keep a reference to the root folder along newly created folder objects or be able to walk through the associated MAPIStore URI and figure out what the root folder URI is. |
| 14 | 3 | Julien Kerihuel | |
| 15 | 1 | Julien Kerihuel | h2. folder.create_folder |
| 16 | 1 | Julien Kerihuel | |
| 17 | 4 | Julien Kerihuel | This function only creates a folder within a existing context. The resulting created folder will have a URI using the same backend that the context it is using. Upon success, the folder is opened and returned within the _void **_ parameter. The function takes in parameter: |
| 18 | 4 | Julien Kerihuel | * _void *parent_folder_: the parent folder object of the folder to be created |
| 19 | 4 | Julien Kerihuel | * _TALLOC_CTX *_: the memory context to use to allocate the new folder upon success |
| 20 | 4 | Julien Kerihuel | * _uint64_t fid_: the folder identifier for this folder |
| 21 | 4 | Julien Kerihuel | * _struct SRow *aRow_: an Exchange data structures which must store PR_DISPLAY_NAME or PR_DISPLAY_NAME_UNICODE (the folder name to be created) |
| 22 | 4 | Julien Kerihuel | * _void **childfolder: the folder object for the newly created folder |
| 23 | 4 | Julien Kerihuel | |
| 24 | 4 | Julien Kerihuel | The SRow structure may also supply the following Exchange properties: |
| 25 | 4 | Julien Kerihuel | * PR_COMMENT or PR_COMMENT_UNICODE: the folder description |
| 26 | 4 | Julien Kerihuel | * PR_PARENT_FID: the folder identifier of the parent folder object |
| 27 | 4 | Julien Kerihuel | * PR_CHANGE_NUM: the new change number |
| 28 | 1 | Julien Kerihuel | |
| 29 | 10 | Julien Kerihuel | h2. folder.delete_folder |
| 30 | 10 | Julien Kerihuel | |
| 31 | 1 | Julien Kerihuel | h2. folder.create_message |
| 32 | 5 | Julien Kerihuel | |
| 33 | 5 | Julien Kerihuel | This function creates a temporary message object. Messages are a bit particular in Exchange, because they are not created through a single transaction. Creating message is the first operation of the process, but message doesn't get available/saved or sent until you respectively call save or submit backend methods. Between create and save/submit, MAPI clients can perform several operations such as: |
| 34 | 5 | Julien Kerihuel | * set or delete properties |
| 35 | 5 | Julien Kerihuel | * add or delete attachments |
| 36 | 5 | Julien Kerihuel | * add or delete recipients |
| 37 | 5 | Julien Kerihuel | |
| 38 | 6 | Julien Kerihuel | Until save/submit is called, this message object remains virtual. However MAPI clients need a way to reference this object within current context until it's saved. This is why OpenChange generates a MID (message identifier) and requests the backend to temporarily create an associated MAPIStore URI. But this MID/MAPIStore URI couple is not stored within the user [[MAPIStore_10_Development_Guide#indexingtdb-URIFMID-wrapper|idexing.tdb]] database. |
| 39 | 6 | Julien Kerihuel | |
| 40 | 6 | Julien Kerihuel | Remember that mapistore calls backend with MID/FID and expect the backend to lookup associated mapistore URI. |
| 41 | 6 | Julien Kerihuel | |
| 42 | 9 | Julien Kerihuel | It is the backend's responsibility to virtual store this message until save/submit is called. If no such mechanism/API exist in your backend or if you want to speed up the process, you can use the ocpf (http://apidocs.openchange.org/libocpf/index.html) library which will store everything for you properly. |
| 43 | 9 | Julien Kerihuel | |
| 44 | 9 | Julien Kerihuel | The function takes in parameter: |
| 45 | 9 | Julien Kerihuel | * _void *parent_folder_: the parent folder object in which the message has to be created |
| 46 | 9 | Julien Kerihuel | * _TALLOC_CTX *_: the memory context to use to create the message object |
| 47 | 9 | Julien Kerihuel | * _uint64_t mid_: the message identifier for this new message |
| 48 | 9 | Julien Kerihuel | * _uint8_t associated_: whether this message is already associated to a file or not (see below) |
| 49 | 9 | Julien Kerihuel | * _void **message_object_: the message object to return |
| 50 | 9 | Julien Kerihuel | |
| 51 | 9 | Julien Kerihuel | Regarding the _associated_ parameter, it is a flag that tells the backend if it already has an associated file for this message or not. Some background is required to understand this concept: |
| 52 | 9 | Julien Kerihuel | |
| 53 | 9 | Julien Kerihuel | When you create a message, you will set properties for the message and finally save it. However, you may not have a 1 to 1 mapping between MAPI properties and what the remote system supports. Many properties are Exchange specific and your remote system may not have associated parameters for them. |
| 54 | 9 | Julien Kerihuel | |
| 55 | 9 | Julien Kerihuel | Here is the crucial part: there is a small amount of information that a remote system is unlikely to map/support but which ARE REQUIRED for the message or folder to be valid/fetched properly by MAPI clients. |
| 56 | 9 | Julien Kerihuel | |
| 57 | 9 | Julien Kerihuel | While you can skip/drop many Exchange properties, you CAN'T skip/drop the required ones. |
| 58 | 9 | Julien Kerihuel | |
| 59 | 9 | Julien Kerihuel | The associated parameter lets your backend know if it already has a file or structure associated to this message in which it stores exchange properties it can't map. |
| 60 | 10 | Julien Kerihuel | |
| 61 | 10 | Julien Kerihuel | h2. folder.delete_message |
| 62 | 10 | Julien Kerihuel | |
| 63 | 11 | Julien Kerihuel | the delete_message operation deletes a message given its message identifier within a given folder. This function takes in parameter: |
| 64 | 11 | Julien Kerihuel | * _void *folder-object_: the folder object in which the message to delete is stored |
| 65 | 11 | Julien Kerihuel | * _uint64_t mid_: the message identifier representing the message to delete |
| 66 | 11 | Julien Kerihuel | * _uint8_t flags_: flags that indicate the kind of deletion |
| 67 | 11 | Julien Kerihuel | |
| 68 | 11 | Julien Kerihuel | Possible deletion flags are: |
| 69 | 11 | Julien Kerihuel | - MAPISTORE_SOFT_DELETE: to virtually delete the message. The message is not physically deleted on the remote system, it is just marked as SOFT_DELETED in the indexing database of the user. It can be recovered at any time. |
| 70 | 11 | Julien Kerihuel | |
| 71 | 10 | Julien Kerihuel | h2. folder.move_copy_messages |
| 72 | 10 | Julien Kerihuel | |
| 73 | 10 | Julien Kerihuel | h2. folder.get_deleted_fmids |
| 74 | 10 | Julien Kerihuel | |
| 75 | 12 | Julien Kerihuel | h2. folder.get_child_count |
| 76 | 12 | Julien Kerihuel | |
| 77 | 12 | Julien Kerihuel | This function retrieves either the number of messages, FAI messages or folders within specified folder. The function takes in parameters: |
| 78 | 14 | Julien Kerihuel | * _void *folder_object_: the folder on which the count has to be retrieved |
| 79 | 12 | Julien Kerihuel | * _uint8_t table_type_: the type of item to retrieve. Possible values are listed below |
| 80 | 12 | Julien Kerihuel | * _uint32_t *rowCount_: the number of elements retrieved |
| 81 | 12 | Julien Kerihuel | |
| 82 | 12 | Julien Kerihuel | Possible values for table_type are: |
| 83 | 12 | Julien Kerihuel | - MAPISTORE_MESSAGE_TABLE: the number of messages within the folder |
| 84 | 12 | Julien Kerihuel | - MAPISTORE_FAI_TABLE: the number of FAI messages within the folder |
| 85 | 12 | Julien Kerihuel | - MAPISTORE_FOLDER_TABLE: the number of folders within the folder |
| 86 | 10 | Julien Kerihuel | |
| 87 | 10 | Julien Kerihuel | h2. folder.open_table |