Re: [IMAP Generator] status webapp

[Stefano Mazzocchi]

Bernhard Huber wrote:

hi,

Probably a typo, but you might want to use

 http://apache.org/cocoon/mail/1.0

thx for the hint

2. the javamail objects are created in reaction to
a request parameter named 'cmd'
cmd = list-folder-messages --> list all messages of a folder,
  headers only
cmd = cat-message-by-uid --> list message header plus its content

3. in the sitemap the RequestParameterSelector chooses depending
on the cmd the right stylesheet for converting the marshalled javamail
xml document to the apache document-v10,

4. A http session holds a MailContext object which stores mail
session, mail store, and folders

that's just a short summary, still some work to do....

how scalable is it going to be? I mean, how much stuff do you hold in memory?

per http session there is one MailContext object
MailContext object holds:
* javax.mail.Session
* bag of javax.mail.Folders
* javax.mail.Messages are not stored in MailContext

that's the first thing I wanted to hear :)

* requesting a list of messages of folders is queryied without requesting the mail content

great, that the second one

* as now marshalling a mail content marshalls the whole mail content
* as now marshalling of javamail objects is done in the MailGenerator,
  i plan to put the javamail objects into the request attribute, making
  these objects available to any generator,
  eg. one xsp picks only folder object from the request attribute,
    another xsp picks only messages.

hope it helps, perhaps you might want to explain
what's your scalablity concerns a bit more detailed :-) ?

It does, I was just worried of memory consumption *and* caching issues, but the above architectural choices seem the right one to me (at least, at this early stage).

i'm not very aware of scalability troubles, except long big volume mail, and lots of mail message per folder.

I would love in the future to have a webmail cocoon block and this generator is an essential piece of it. But it must scale to very big email usages (like thousands of email messages in hundreds of mail folders) or nobody will use it.

--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]