You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bernhard Huber <be...@a1.net> on 2002/12/29 19:48:57 UTC
[IMAP Generator] status webapp
hi,
fyi i'm just working on MailGenerator, as there are some other people
working on this kind of stuff, i'd like to describe the solution
i'm working on:
1. a MailContentHandlerDelegate marshal javamail objects like
folder, messages to xml
using namespace http://org.apache/cocoon/mail/1.0
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....
regards bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [IMAP Generator] status webapp
Posted by Stefano Mazzocchi <st...@apache.org>.
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 <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [IMAP Generator] status webapp
Posted by Bernhard Huber <be...@a1.net>.
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
* requesting a list of messages of folders is queryied without
requesting the mail content
* 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 :-) ?
i'm not very aware of scalability troubles, except long big volume mail,
and lots of mail message per folder.
regards bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [IMAP Generator] status webapp
Posted by Stefano Mazzocchi <st...@apache.org>.
Bernhard Huber wrote:
> hi,
> fyi i'm just working on MailGenerator, as there are some other people
> working on this kind of stuff, i'd like to describe the solution
> i'm working on:
>
> 1. a MailContentHandlerDelegate marshal javamail objects like
> folder, messages to xml
> using namespace http://org.apache/cocoon/mail/1.0
Probably a typo, but you might want to use
http://apache.org/cocoon/mail/1.0
instead.
> 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?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Sandbox?
Posted by Bernhard Huber <be...@a1.net>.
hi,
>
> I have not yet committed the current mail patched because of a dilemma I
> hope you guys can help me solve.
sorry, no definitive this-is-the-way-to-go
from me.
>
> I can put it in the Cocoon scratchpad, and have it committable only by
> core committers, or put it in cocoon-apps, and have the authors come in
> with a lower barrier to entry.
that's the way we do it now, with the danger that its put there once
and gets forgotton...
>
> But then, is it an app? Souldn't it be a block? Same question for the
> new CVS stuff. What about a more open sandbox? What about a Cocoon
> blocks CVS? What about....
Hm, an app uses blocks, and may define some app specific stuff.
parts of stabilized app may be converted to blocks, that's
the way i see it.
for example the new cvs generator is put into scratch pad, sample
pages are put into scratchpad/webapp.
regards bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Cocoon Sandbox?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bernhard Huber wrote:
> hi,
> fyi i'm just working on MailGenerator, as there are some other people
> working on this kind of stuff
[...]
I have not yet committed the current mail patched because of a dilemma I
hope you guys can help me solve.
I can put it in the Cocoon scratchpad, and have it committable only by
core committers, or put it in cocoon-apps, and have the authors come in
with a lower barrier to entry.
But then, is it an app? Souldn't it be a block? Same question for the
new CVS stuff. What about a more open sandbox? What about a Cocoon
blocks CVS? What about....
Please help, tell me what to do, I'm confused...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [IMAP Generator] status webapp
Posted by Bernhard Huber <be...@a1.net>.
hi,
as holiday ends, the Cocoon Mail stuff gets finalized....
Stefano Mazzocchi wrote:
> Bernhard Huber wrote:
>
>> Now I'm finalizing the stuff, in the next days i'd like to write some
>> doc, and put it into scratchpad.
Just to be sure:
i'm going to create a new org.apache.cocoon.mail directory
putting the mail releated stuff there.
moreover i'll create an mail directory in the scratchpad webapp
area.
Auxilliary sitemap components of the Webmail application i'm going
to put into
org.apache.cocooon.generation,
org.apache.cocooon.seclection, etc.
that's all releates to the main-trunk, and not for the 2_0_3 branch.
just to be sure that scratchpad is the right are to put everything...
ups, need to add the cocoon apache header to eache java source
>
> I love it!!!
>
> IMAP reading and CVS reading/writing were the things that Cocoon was
> missing. I see very exciting things coming up this year :)
>
okay, seeing forward to get it done.
I was very surprised how easily a static html version of the webmail
application could get generated, as more as i use Cocoon, the more
i love it, see
http://members.a1.net/berni_huber/cocoon-webmail/howto-cocoon-webmail.html
As said very often, once you understand the cocoon-way, things get
very easy.
regards bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [IMAP Generator] status webapp
Posted by Bernhard Huber <be...@a1.net>.
hi,
>
> IMAP is pretty easy to add, I think my IMAPGenerator was committed to CVS
> into scratchpad, so check it out if you need any examples. I'm looking
> forward to seeing this stuff in scratchpad soon!
comming soon,
and thx for intial IMAPGenerator stuff
bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [IMAP Generator] status webapp
Posted by Tony Collen <tc...@neuagency.com>.
On Fri, 3 Jan 2003, Stefano Mazzocchi wrote:
> Bernhard Huber wrote:
> > hi, team
> >
> > some status notes about the MailGenerator.
> >
> > The MailGenerator is dead, long live MailAction!
:( ! My baby! :) Oh well, I suppose better things are to come...
&snip;
> > some quick snapshot of the mail webapp:
> > http://members.a1.net/berni_huber/cocoon-webmail-1.gif, and
> > http://members.a1.net/berni_huber/cocoon-webmail-2.gif.
Geez, you're going to do all my work for me! Not a bad thing though.
It's looking really good.
> > ah by the way as i have not imap access all the time i wrote an mbox
> > provider for accessing mbox files, downloaded the cocoon-user mboxes,
> > and do testing with these mboxes, but this needs some work as writing
> > an mbox to jisp writer, ....
IMAP is pretty easy to add, I think my IMAPGenerator was committed to CVS
into scratchpad, so check it out if you need any examples. I'm looking
forward to seeing this stuff in scratchpad soon!
> I love it!!!
>
> IMAP reading and CVS reading/writing were the things that Cocoon was
> missing. I see very exciting things coming up this year :)
Yep yep. Semi-OT, I finally checked out the third Cocoon book, and it's
looking stellar... I think Amazon has it on sale.. must pick up... so much
to do and learn, so little time.
Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [IMAP Generator] status webapp
Posted by Stefano Mazzocchi <st...@apache.org>.
Bernhard Huber wrote:
> hi, team
>
> some status notes about the MailGenerator.
>
> The MailGenerator is dead, long live MailAction!
>
> I moved over to a MailAction instead of a MailGenerator.
> Some explanation to this move:
> * MailAction puts javamail objects as XMLizable objects
> into the request attribute
> * Generators xsp page can pick these XMLizable objects
> and generate XML very easily,
> eg.: <xsp-request:get-attribute name="messages" as="object"/>
> * MailAction understands a series of commands, which triggers
> what javamail object should get generated,
> today following commands are supported:
> cat-folder : put folder object into request attribute
> list-folder-messages : put messages of a folder into request attribute
> search-folder : use javax.mail.search for searching for messages in
> folder
>
> I moved to MailAction, as it is still to access the original javamail
> objects, folder, message, etc, and to decide later in the xsp for
> example what kind of object should get marshalled.
>
> Now I'm finalizing the stuff, in the next days i'd like to write some
> doc, and put it into scratchpad.
>
> to-do:
> * accessing some strange mail-body
> * generating and displaying a list of attachments
> * brush of example Mail webapp.
>
> some quick snapshot of the mail webapp:
> http://members.a1.net/berni_huber/cocoon-webmail-1.gif, and
> http://members.a1.net/berni_huber/cocoon-webmail-2.gif.
>
> ah by the way as i have not imap access all the time i wrote an mbox
> provider for accessing mbox files, downloaded the cocoon-user mboxes,
> and do testing with these mboxes, but this needs some work as writing
> an mbox to jisp writer, ....
>
>
> any comments?
I love it!!!
IMAP reading and CVS reading/writing were the things that Cocoon was
missing. I see very exciting things coming up this year :)
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [IMAP Generator] status webapp
Posted by Bernhard Huber <be...@a1.net>.
hi, team
some status notes about the MailGenerator.
The MailGenerator is dead, long live MailAction!
I moved over to a MailAction instead of a MailGenerator.
Some explanation to this move:
* MailAction puts javamail objects as XMLizable objects
into the request attribute
* Generators xsp page can pick these XMLizable objects
and generate XML very easily,
eg.: <xsp-request:get-attribute name="messages" as="object"/>
* MailAction understands a series of commands, which triggers
what javamail object should get generated,
today following commands are supported:
cat-folder : put folder object into request attribute
list-folder-messages : put messages of a folder into request attribute
search-folder : use javax.mail.search for searching for messages in
folder
I moved to MailAction, as it is still to access the original javamail
objects, folder, message, etc, and to decide later in the xsp for
example what kind of object should get marshalled.
Now I'm finalizing the stuff, in the next days i'd like to write some
doc, and put it into scratchpad.
to-do:
* accessing some strange mail-body
* generating and displaying a list of attachments
* brush of example Mail webapp.
some quick snapshot of the mail webapp:
http://members.a1.net/berni_huber/cocoon-webmail-1.gif, and
http://members.a1.net/berni_huber/cocoon-webmail-2.gif.
ah by the way as i have not imap access all the time i wrote an mbox
provider for accessing mbox files, downloaded the cocoon-user mboxes,
and do testing with these mboxes, but this needs some work as writing
an mbox to jisp writer, ....
any comments?
regards bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org