On Fri, 2010-06-04 at 11:13 +0200, Julien Kerihuel wrote: > 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
Follow-up of this initial email.
Brad and I had a discussion on IRC + performed some other tests.
1. Does the parent object of the fid to open in OpenFolder need to be
its parent?
No. Within a hierarchy similar to Inbox -> test1 -> test2 -> test3, we
were able to open test3 folder directly after a Logon call.
2. Using above example, could it work if parent object used to open the
test3 folder (within Inbox) is the Calendar folder?
Yes it does.
3. Using the fsocpf uri, we could directly open the message without
opening subsequent folders (path to message). This is correct for fsocpf
backend, but may not be implementable for other kind of backends.
Furthermore mapistore backends should remain as atomic as possible. It
would really make it difficult for backend implementors if they had to
handle a list of special case within the scope of a given atomic
operation.
4. Furthermore, if we were opening a message directly and if we were
calling SetProps on it, for example to mark the message as "read". This
means we would have to open the parent folder and update its properties.
In any case we would have to open the folder containing the mid.
5. To be as generic as possible with regards to backend, this mapistore
API will handle the creation of the handle tree (from store object down
to mid or from subsequent folder down to mid if some folders were
already opened). This hierarchy being attached to a handles tree, we'll
benefit from existing mechanisms to delete it as a whole when not needed
anymore and benefit from it being already opened to accelerate further
open/read operations.
6. The new improved design is to:
- have a $user_index.tdb database with mid = mapistore_uri and
fid = mapistore_uri records stored within mapistore/$user/
directory
- this database will be managed by mapistore
- we will provide an API to:
- create the indexing database
- add/delete entries within indexing database
- retrieve the mapistore URI associated to a fid or mid
- use the URI to do the underlying magic and access the
file content (opening subsequent folders, attaching them
to a common parent folder etc.)
The API may be improved upon development, but the overall idea is here
and sounds consistent.
What we will need to think about in the future is how to keep this
database consistent when backends do modifications on their own: user
delete message from IMAP backend etc.
Cheers,
Julien.
--
Julien Kerihuel
[email protected]
OpenChange Project Manager
GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
