- This page was last modified 21:09, 30 July 2007.
- This page has been accessed 4,139 times.
- Privacy policy
- About Buni.org
- Disclaimers
Contents |
Meldware is a Free/Open Source Collaboration (mail and calendaring) Server. Written in Java and runs on top of a most JDBC3-enabled RDBMS (primarily PostgreSQL, MySQL, and Oracle).
The main goal of Meldware is interoperability with your infrastructure. Java is a very good tool for building cross-platform applications, so we don't have to dictate a particular operating system or CPU type. The latest version (5 or above is required for Meldware) provides a very fast JIT compiler, so applications, after a short warm-up period, runs at near native speed. One of Java's other cross-platform successes is JDBC. Just about every database provides a driver for JDBC, making interoperability easier.
The biggest benefit that an RDBMS back-end supplies is manageability. Many organisations already have a database of choice and employ specialised DBAs for support and maintenance. For these organisations Meldware should slot in easily and those organisations can reuse their DBA resources to manage their email. Most RDBMS supply a number of reliability features that make them attractive a store for email, including ACID transactions and powerful back capability.
We do plan to support an embedded RDBMS (probably Apache Derby or similar) as well as our own file-based store for mail bodies.
For the 1.0 release, Meldware will be tested on Oracle, PostgreSQL, and MySQL. At moment our recommended database is PostgreSQL. Apart from being Free and Open Source (we like that) it is the best in terms of BLOB performance. Meldware stores all of the bodies of email messages in a BLOB column in the database. To ensure memory scalability data is streamed into the BLOB column, avoiding holding the whole message in memory (imagine what would happen if it held 20MB+ messages in memory). PostgreSQL supports this really well with its LargeObjectAPI. MySQL supports BLOBs, but does not support the streaming aspect particularly well. The JDBC driver either stores all of the data into memory before writing to the DB or it tries to emulate streaming using an algorithm that is O(n2) complexity. To work around this we implement our own paging mechanism that splits large mail bodies across a number of rows. This paging supports streaming, but not with the performance of a database that supports BLOB streaming natively.
Strictly speaking no. Meldware does provide the same services as an MTA, but it integrates with a backend store that is optimized for MIME (although mails not sent to local users are not parsed). This is required to do IMAP efficiently. Moreover, Meldware's SMTP service is technically separate from the SMTPSender. Moreover there are various components set up to take incoming messages, analyze them, deliver them and forward them via the SMTPSender. While Meldware has benchmarked very nicely and should perform quite nicely by comparison to MTAs such as sendmail and postfix, it isn't the target of Meldware to replace these so much as augment them.
No. Meldware can receive and deliver the mail just fine. You may however have existing stuff like ClamAV or SpamAssasin that you want to use (although Meldware incorporates its own spam technologies). You may also want an edge filter to prevent DoS attacks against your main mail cluster. This may or may not incorporate an MTA. If you don't know what any of this means maybe you should contact sales (@) bunisoft (.) com. :-)