No matter how terrific a webmail application can be, people will almost never drop their regular mail client.
 
You can make a webmail way more efficient, featured, than a heavy mail client, users will just think it will be useful to get to their mailbox when they are out of the office. But they will never drop Thunderbird.

This is too bad since one of the goal of CPSMailAccess, the upcoming CPS webmail, is to fill the gap between datas contained in groupwares and intranets, making mails behave like any other portal document. And keeping Thunderbird as the master mail application won't help on this.

After looking at users behavior, I found out that the only reason they act that way is the lack of desktop integration of a webmail app.

A web application sleeps on your desktop, and this is so annoying to users that they just close the darn' firefox window.

More desktop integration and interaction are the keys.

If you provide a small desktop application that pops whenever a mail is dropped in your mailbox, and let you quickly get to your webmail inbox, or let you quickly get to the mail editor, people will drop their mail client.

Thanks to Python this can be done quite easily to support most plateforms, and I will probably start to code later a small desktop app to be released within CPSMailAccess.

That reminds me a thread in Z3lab Mailing list we had, involving people from the Z3 ECM project: I keep on thinking that Zope can be the central part of intranet and desktop apps and that a lot of small of desktop apps interacting with zope servers will start to come up in the next years.

The main problem with wiki syntaxes is that they have almost always fixed features. Some wikis are extensible, like Trac, who let you create macros.

CPSWiki is going to have its own system of macros, that will give the user the ability to execute scripts.

Those scripts will be able to interact with the portal through an execution context that will make the portal accessible to the code.

Zwiki has a similar approach in http://zwiki.org/ZwikiCookbook by letting the user execute dtml.

The more interesting way to do it is to create a wiki namespace and to keep all scripts in the wiki folder. This namespace will allow scripts to interact and
 users to construct complex features. (dynamic graph creation, etc.)

This has to come with a library of base scripts that the user can start to manipulate.

Let's get rid of all thoses heavy CMS features and get back to a good o'wiki to create all our sites ;)

Everytime I am starting to design round boxes, I'm having a big headache.

It's just too complicated for me. Whenever i get close to a good looking box, wich content does not run away on the sides, looking good on my Firefox, and behaving well in my CPS, I get depressed when I switch into IE.

Now I think I will always use this recipe for now one :

gecko engine comes with its own border-radius style, not yet validated in CSS3 but it should be sometimes,

   #mailBody {

     background-color: white;

     margin-top: 10px;

     padding:8px;

     -moz-border-radius-topleft: 12px;

     -moz-border-radius-topright: 12px;

     -moz-border-radius-bottomleft: 12px;

     -moz-border-radius-bottomright: 12px;

   }

This is clean, looks good, and cut off all those small pictures I was trying to stick together.

See the attached file for a screenschot

 I have successfully set up and used ZAsync for webmail folder synchronisations, here's a small summary on what I have done.

Setting up ZAsync with Zeo

The first step was to set up a zeo installation with a few zope nodes.This is quite easy and usual, thanks to Zope smart architecture.

Then I have installed zasync product and created a singleton object called "Asynchronous Call Manager" in the root of the Zope.

This object provides a few methods that can be called to delegate some work to zasync.

The next step was to launch the ZAsync client that will actually run asynchronous calls on the ZODB.

ZAsync comes with a nice conf file, similar to the zope one, where you can provide informations like the adress and port of the ZEO server and set up things like logging or path.

path configuration is very important for instance, when you run a Zope2/Five/Zope3 configuration.

When everything is  set up, the client is launched and listen to incoming calls, sent by the Asynchronous Call Manager

How does it work ?

Zasync maintains a custom BTree called BForest, that holds commands to be run. Commands to be run are sent to an object called Asyncrhonous Call Manager. A client is launched besides Zope. The client looks upon the tree to see if there's some tasks to do and run them.

Why webmail needs more features

Now using one asynchronous call manager with one client can't be enough for a webmail that's supposed to handle something like 3000 people on a intranet.
I need to run several zasync clients on several servers to speed up background processes. I was starting to think about it when Gary Poster told me how to do it :
Setting up several asynchronous call manager, each one with a dedicated client. and make some kind of top function to send calls to call managers, with load balancing.

This is easy to set up since we can specify  in the client conf file the target call manager.

ZAsyncLoadBalancer Product

Since this mechanism will propably be needed in other projects, I have decided to create a small Zope product in charge of all zasync clients, that will keep a collection of asynchronous call manager and distribute calls to them according to their load.

This product will probably be callable in a high level way and fully integrated to our CMS.

Stay tuned for part #3, with a first version of ZAsyncLoadBalancer hopefully :)