| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BLOB properties had a couple of intended purposes:
* Allow large payloads to be streamed directly to disk, and then be
handled by reference.
* Allow zero-copy handling.
* Keep the database values compact so we can avoid traversing large
BLOBS.
However, they came at the cost of code-complexity, and we lost all the
benefits of our storage layer, such as transactions.
Measurements showed, that for email (the intended primary usecase),
the overhead is hardly measurable, with most parts performing
better, or at least not worse. We additionally also gain file-system
independence, which may help on other platforms.
The biggest drawback is probably that large payloads need to be written
to disk twice, because of the synchronizer queue (once for the queue,
once for the actual data).
|
| | |
|
| | |
|
| |
|
|
|
| |
Adding the mail to cyrus imap somehow broke with cyrus 3.0.
We're now creating the mail instead, before trying to sync it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Otherwise the test is not aborted because the job doesn't get any error
set
|
| |
|
|
|
|
|
| |
IMAP always requires CRLF, and so does the MIME standard, KMIME expects
LF-only.
We now just try to always use CRLF on disk, but convert LF-only messages should
we have to (e.g. because copied over from maildir or so).
|
| | |
|
| | |
|
| |
|
|
|
| |
...we used to accidentally move external blobs after the property was
lost when storing the modificatoin in the queue.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead we make it part of the plugin.
This ensure we also have access to the proper capabilities when creating
a resource via sinksh.
|
| | |
|
| |
|
|
|
| |
... because we really just enqueue the request and then wait for the
notification.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of a single #define as debug area the new system allows for an
identifier for each debug message with the structure component.area.
The component is a dot separated identifier of the runtime component,
such as the process or the plugin.
The area is the code component, and can be as such defined at
compiletime.
The idea of this system is that it becomes possible to i.e. look at the
output of all messages in the query subsystem of a specific resource
(something that happens in the client process, but in the
resource-specific subcomponent).
The new macros are supposed to be less likely to clash with other names,
hence the new names.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
version
|
| | |
|
| | |
|
| | |
|
| |
|
