What would be amazing is the ability to use a remote database, for example postgres or mysql.

That will allow people to use a central database server for email. Backup will be easier, working from different locations will be easier. On some environments, using NFS to share the homes, SQLlite could be problematic, as is very dependent on locking and NFS is very prone to problems with locks.

Setting a database server on a office lan is much more easy and doable for not very high skilled people. A setup like David’s one for Fargo city are out of question for many small offices, but a central database of emails is very doable.

Please, consider database abstraction during the design & implementation (if possible). Being able to use different databases will be amazing.

Thanks!

I really depend on Evolution for may day to day activities and it would be really nice if it uses less memory to let my crappy system run faster with some other memory hungry applications

Keep up the good work, thanks a lot.

Cheers.

At 8am in the morning, I literally have 100+ people logging in and starting email within a 10 minute window. In theory, the current cache code should simulate something similar to this design, right? Hit me up anytime if I can assist.

While integrated with Evolution, this is unlikely.

For me it was for example not possible to depend on the entire evolution-data-server stack just for the camel pieces.

Although sure, a lot of E-mail clients will consume the other pieces of evolution-data-server too.

That by itself is not a reason to bundle it. There are equally easy E-mail clients needed that don’t need any of evolution-data-server’s functionality. For those E-mail clients, it’s just more difficult to cope with having to put all those eds pieces on their flash disk.

Camel, however, is at this moment not in a very good shape in my opinion. But if more people would work on it, it could improve a lot. I think.

But anyway. Good luck with the experiments. You’ll need it

Philip, as I have said before I’m not against it as a separate project. But it it is reaaally required, we can do it. But that shouldn’t be the stopping point for anything. If I implement it well and it works fine. It can make it into tinymail and well, I won’t mind to have it as a separate project then. I see that now tinymail is used in things like modest etc. which may be benefited as well. So we can discuss this may be a little later.

I would love to have an excellent replacement for that part of Tinymail that is now camel-lite. I’ve always seen camel-lite as a temporary fork, although right now the changes that have been made are all needed and have gotten quite large in their nature.

So I fear it’ll take quite some time before upstream Camel can do all those things (in some pluggable way).

However. Again, if your summary implementation indeed works well (if you implement it right, it will. Because conceptually it can definitely work very well), then you’ll see it being used in Tinymail too. Probably in a 2.0 version.

Because if it does work well, I don’t see any reason why I should hold to my current mmap-based implementation (which was a clever hack, but still a hack).

Nat has been in love with Sqlite for a while as a replacement for the db-like APIs.

Miguel.

Right now it’s unfinished and experimental. So I’m waiting for the results before making a decision.

Tinymail’s summary implementation achieves most of the benefits already, but that doesn’t mean that it was implemented in an ideal way.

Perhaps this is indeed better and then there will be a lot of overlap.

I’m working on a few of my own experiments that don’t change the way things work as much as this idea, maybe those experiments will be better.

Who knows? In any case, people are working on Camel. That by itself is overlap with Tinymail already.