Hi List,
For the past two days, I have been working on rewriting the libocpf
library internals to match our server side expectations. the OCPF
library is now:
- reentrant (multi-process / thread friendly)
- makes use of an internal context management system and ref
count:
- it limits the number of contexts required to be
created
- it provides the semantic needed to have locking
mechanism when different MAPI instances tries to access
the same folder/message
- the API now loads OCPF data into memory and offer mechanisms
to prevent from accessing the disk each time we need to fetch a
property.
- the new implementation now provides semantics required to
quickly write SetProps for mapistore.
I thought this would be enough and had planned to start OpenMessage
implementation today, but "Que nenni". This was without noticing an
implementation detail that does require our attention.
This ROP uses as a InputHandleIndex which can be either a Store object
or a Folder object. None of them needs to be the parent folder of the
message. It just requires to be within the same store.
I have given a test to this behavior:
- using "openchangeclient --fetch-items=Mail" I retrieve the
FID/MID couple
- in fetchmsg.c attached to this email I replace fid/mid with
the fetched values. (I was too lazy to write a nice program -
just wanted a quick hack to confirm)
Exchange server is indeed able to retrieve the message directly after
Logon call when we know the FID/MID.
For developers implementing clients, this can be pretty useful.
For us developing the server, it clearly requires additional work and
server semantics to be implemented ;-)
In my understanding, it means we need to implement indexing databases
that are user (store) specific. It doesn't look reasonable to have to
search then entire store to find the associated message location.
2 models came up.
In the first one we have 2 databases, one linking folder hierarchy and
the other linking message ID to folder ID. The design was nice and
robust, but we were loosing all the mapistore benefits.
In the second one we have a single database which directly makes use of
the mapistore URI. I think this one makes better use of the existing OC
server API and design.
$user_indexing.tdb
mid = fsocpf://path/to/mid
fid = fsocpf://path/to
When OpenMessage is called, we retrieve the input handle index to know
which store it refers to, then opens the proper $user_indexing.tdb.
We search for OpenMessage request fid and mid, ensures they exist and
are related, then takes the mid uri and process it within OpenChange
server framework with recursive OpenFolder calls until we access the
message.
If the whole folder hierarchy is already opened, no problem it will just
retrieve the context and go straight through to the next one. If it's
not, we create a new handle and attach it to the hierarchy.
At the end of the process, we have access to the message, all parent
folders are opened and further operation will be much quicker.
If we quit or release the FID object, then the handle API and
emsmdbp_object destructor mechanism do their job and clean/release
everything.
Just some thoughts before I start implementing this.
Cheers,
Julien.
--
Julien Kerihuel
[email protected]
OpenChange Project Manager
GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
/* Fetch directly a message OpenChange Project Copyright (C) Julien Kerihuel 2010 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include <libmapi/libmapi.h> #define DEFAULT_PROFDB "%s/.openchange/profiles.ldb" int main(int argc, const char *argv[]) { enum MAPISTATUS retval; TALLOC_CTX *mem_ctx; struct mapi_session *session = NULL; mapi_object_t obj_store; mapi_object_t obj_message; char *profdb; uint64_t fid,mid; char *profname; mem_ctx = talloc_named(NULL, 0, "fetchmail"); /* Initialize MAPI */ profdb = talloc_asprintf(mem_ctx, DEFAULT_PROFDB, getenv("HOME")); retval = MAPIInitialize(profdb); MAPI_RETVAL_IF(retval, retval, mem_ctx); SetMAPIDumpData(true); SetMAPIDebugLevel(10); /* Find Default Profile */ retval = GetDefaultProfile(&profname); MAPI_RETVAL_IF(retval, retval, mem_ctx); /* Log on EMSMDB and NSPI */ retval = MapiLogonEx(&session, profname, NULL); MAPI_RETVAL_IF(retval, retval, mem_ctx); /* Open Message Store */ mapi_object_init(&obj_store); retval = OpenMsgStore(session, &obj_store); MAPI_RETVAL_IF(retval, retval, mem_ctx); mapi_object_init(&obj_message); fid = 0x1D28000000000001; mid = 0x85282B0000000001; retval = OpenMessage(&obj_store, fid, mid, &obj_message, 0x0); Logoff(&obj_store); MAPIUninitialize(); return (0); }
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
