Commit message (Collapse) | Author | Age | |
---|---|---|---|
* | Cleanup | Christian Mollekopf | 2018-05-23 |
| | |||
* | Store all BLOB properties inline. | Christian Mollekopf | 2018-02-06 |
| | | | | | | | | | | | | | | | | | | | | | 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). | ||
* | Ensure we copy all blobs when copying to another resource | Christian Mollekopf | 2017-10-09 |
| | |||
* | Deal with both CRLF and LF mime messages. | Christian Mollekopf | 2017-06-14 |
| | | | | | | | 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). | ||
* | Move blob files on move to the same location like when a client moves. | Christian Mollekopf | 2017-03-07 |
| | | | | | | Otherwise if the source resource manages to clean up the revision before the target resource gets to process the new entity, then the blob file is gone already. | ||
* | Interresourcemovetest/fixed interresourcemove | Christian Mollekopf | 2016-12-06 |
We cant take the identifier from the entity where we just cleared the identifier. |