We are no longer sure that WebDAV is still relevant. We recently released a new HTTPS/HTTP client component (see http://www.rebex.net/https/ for details) and WebDAV would be a relatively simple extension on top of that. But it looks like WebDAV is rarely used now – it has been superseded by various REST APIs, so perhaps that’s what we should look into. What do you think?
HTTP/HTTPS client component supports GET/PUT commands out-of-the-box, but to get drag&drop functionality working seamlessly, you would most likely have to add a bit of custom code that adds COPY, MOVE and possibly MKCOL. We'll keep this under review for now and try to find a way to eventually fit it into our roadmap. In the meantime, we will try to help any customers trying to achieve this using our HTTPS/HTTP client component.
Is WebDAV still relevant? We recently released a new HTTPS/HTTP client component (see http://www.rebex.net/https/ for details) and WebDAV would be a relatively simple extension on top of that. But it looks like WebDAV is rarely used now - it has been superseded by various REST APIs, so perhaps that's what we should look into. What do you think?
And for accessing MS Exchange (or Office365 Outlook), Rebex Secure Mail includes an EWS component (see http://www.rebex.net/secure-mail.net/features/ for details).
I'm afraid I don't quite understand how why would splitting large files into multiple transfers result in any improvement in transfer speed. I can only imagine one scenario where this would actually work - an FTP server or some device along the that limits bandwidth per-session instead of per-IP. In this case, splitting the transfer into multiple parts and transferring them simultaneously would indeed result in a massive improvement to transfer speed. However, why not simply configure the FTP server to limit bandwidth per-IP instead of per-session?
Dropbox doesn't support FTP protocol. Providing a custom Dropbox API sounds resembling Rebex FTP API sounds like an interesting idea, but if that's what you are interested in, please vote for this instead: https://rebex.uservoice.com/admin/forums/18155-rebex-net-components/suggestions/3330268-support-for-accessing-cloud-storage-services-like
It’s true that many of the methods/properties in IMAP/POP3/EWS are equivalent, but there is not exactly a 1:1 match there – the three protocols are very different, which means the usability of a common interface would be quite low. Basically, it would be a unified API for IMAP/POP3/EWS that look just like POP3.
It's true that many of the methods/properties in IMAP/POP3/EWS are equivalent, but there is not exactly a 1:1 match there - the three protocols are very different, which means the usability of a common interface might be quite low.
This is still on our list of possible improvements. In the meantime, it can be achieved with a bit of custom code - see http://forum.rebex.net/6292/is-there-any-plan-to-implement-dkim-signing?show=6298#a6298 for details.
4 votesAdminLukas Matyska (Admin, Rebex) responded
From version 2016 R3 you can handle these objects using plain XML, that is basically raw SOAP request. More high-level API is still planned in the future.
Thanks for letting us know! The next version will make it possible to retreive and update these additional Exchange object by directly manipulating their XML representation, and we still plan to add a more high-level API in the future.
Actually, I don't think XTS-AES might not be suitable for this scenario.
XTS-AES is a block cipher intended for disk encryption, which makes it perfectly suitable for encrypting large data streams, but not-at-all-suitable for encrypting individual database table fields or records. Simply said, XtsStream is an alternative to .NET's CryptoStream, but supports random access (seeking) and both reading and writing.
Some of our clients are using XtsStream to encrypt databases, but they layer their database engine on top of XTS-AES, not the other way around.
Hello, I just posted a sample code for free-form search that works with the current version of Rebex IMAP: http://forum.rebex.net/questions/123/imap-search-with-free-form-text/124#124
The problem with this kind of free form search approach is that it can get quite nasty - unless you only use very simple searches, you have to be familiar with the rest of RFC 3501 (know how to quote special characters, how to use modified UTF-7 to encode international characters, etc.). One of our design goals was to shield the user from ever having to deal with IMAP internals like this.
We already support S/MIME, so it is possible to use Rebex Mail libraries as a base for an AS2-enabled application with the help of .NET's HttpWebRequest class to do the HTTP part. Once we have a custom HTTP component (see another request), building an AS2 component out of S/MIME and HTTP will be rather simple.