On Sat, 2010-06-19 at 08:23 +0000, Brad Hards wrote: > This is an initial implementation of RopEmptyFolder. There is still > some work to do (in terms of recursive handling, deleting of messages, > and soft deletion), but I'd like to get some discussion of the general > approach first. > > I'm particularly keen to decide whether the "flag" variations should > be handled by the server, libmapistore core, or by the backend. At > this stage, I think server is looking the best.
This is indeed an interesting discussion about the server semantics. I
would rather implement this behavior at mapistore level.
If we implement flag handling at server level, then other providers
wouldn't really benefit from mapistore features. Let say we write a
single-unit test application, we would have to implement the server
logic within the application.
Regarding soft-deletion, I think most of the API is made private to
mapistore. I don't think an application or server should have to handle
soft-deleted files differently or even have to reference them within
indexing database. It is up to mapistore to handle this transparently.
Regarding recursive deletion of folders or/and messages, I'm afraid that
implementing the behavior too high level would lead in extending the
backend's API and pointer on functions. I'd rather try to keep them to
the minimum.
A possible solution would be to have wrapper/assessors in mapistore
which perform a single operation such as delete_folder,
delete_folder_and_messages delete_folders_only etc. Those functions
calling the backend with a specific flag and letting the backend
performing the associated operation.
So it would be at 3 level:
- server side: you call the correct mapistore function that
matches the behavior you want to implement
- mapistore interface: assessors that call backend with the
corresponding flag
- mapistore backend, implement the behavior depending on the
flag passed in argument.
Cheers,
Julien.
PS: I have a found a much better/clean way to handle soft deletion in
the indexing database. I'll work on this after I finish this python
bindings work.
--
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
