Menu
▾
▴
jwma-devel
|
From: Pavel D. <pav...@gm...> - 2005-05-19 21:37:40
|
Hi!
I've posted this on the forum, but since sf has really crappy forum support=
, I'm
now no longer able to view that forum. So I post it here.
The problem happens when I open up contacts' groups and choose a
person to mail to. I compose my mail and press send. Then i get this
stacktrace (not complete, but this seems to be the essensial part).
I've had this problem before when my contacts-plugin wasn't doing
stuff right, but now I made sure that every method I've written
produces a debug-output and I can't see any in the log, so my classes
aren't even used:
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.JwmaMultipartRequestHandler] Created
net.wimpi.webmail.mail.util.JwmaMultipartRequestHandler@faaa93
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.MultipartRequest] Processing request
data..
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.MultipartRequest] Got Length..
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.MultipartRequest] Got content-type
(multipart/form-data;
boundary=3D---------------------------28228175622324)
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.MultipartRequest] Streaming in...
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.FormdataMultipart] Adding action=3Dsend
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.FormdataMultipart] Adding
to=3Dpavel.denissov@localhost
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.FormdataMultipart] Adding CCTo=3D
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.FormdataMultipart] Adding BCCTo=3D
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.FormdataMultipart] Adding subject=3DTestar
hmm...
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.FormdataMultipart] Adding body=3DHaj din
fisk.
Funkar det h=E4r?
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.util.FormdataMultipart] Adding
mailidentity=3Djwma-e014e38efd41a6042b1a46c74c81528a
2005-05-19 23:20:59,589 DEBUG
[net.wimpi.webmail.mail.controller.ComposeForm]
setMailidentity():jwma-e014e38efd41a6042b1a46c74c81528a
2005-05-19 23:20:59,609 DEBUG
[net.wimpi.webmail.mail.controller.ComposeForm] setBody():Haj din
fisk.
Funkar det h=E4r?
2005-05-19 23:20:59,609 DEBUG
[net.wimpi.webmail.mail.controller.JwmaAction]
net.wimpi.webmail.mail.controller.JwmaSession@18787c9
2005-05-19 23:20:59,609 DEBUG
[net.wimpi.webmail.mail.controller.JwmaSession]
setActionForm():form=3Dnet.wimpi.webmail.mail.controller.ComposeForm@17e72d=
1
2005-05-19 23:20:59,609 DEBUG
[net.wimpi.webmail.mail.controller.ComposeAction]
doDispatchActions():action=3Dsend
2005-05-19 23:20:59,609 DEBUG
[net.wimpi.webmail.mail.controller.JwmaSession] Stored request bean:{}
2005-05-19 23:20:59,609 DEBUG
[net.wimpi.webmail.mail.model.JwmaComposeMessage] openDraft():is
draft=3Dfalse
2005-05-19 23:20:59,619 INFO [STDOUT] DEBUG SMTP: useEhlo true, useAuth tr=
ue
2005-05-19 23:20:59,619 INFO [STDOUT]=20
DEBUG: SMTPTransport trying to connect to host "172.30.5.33", port 25
2005-05-19 23:20:59,699 INFO [STDOUT] DEBUG SMTP RCVD: 220 ESMTP
Service (Lotus Domino Release 6.5.4) ready at Thu, 19 May 2005
23:24:17 +0200
2005-05-19 23:20:59,699 INFO [STDOUT] DEBUG: SMTPTransport connected
to host "172.30.5.33", port: 25
2005-05-19 23:20:59,709 INFO [STDOUT] DEBUG SMTP SENT: EHLO pavel
2005-05-19 23:20:59,739 INFO [STDOUT] DEBUG SMTP RCVD: 250- Hello
pavel ([172.30.5.104]), pleased to meet you
250-HELP
250-SIZE
250 PIPELINING
2005-05-19 23:20:59,739 INFO [STDOUT] DEBUG SMTP Found extension "HELP", a=
rg ""
2005-05-19 23:20:59,739 INFO [STDOUT] DEBUG SMTP Found extension "SIZE", a=
rg ""
2005-05-19 23:20:59,739 INFO [STDOUT] DEBUG SMTP Found extension
"PIPELINING", arg ""
2005-05-19 23:20:59,739 DEBUG
[net.wimpi.webmail.mail.util.JwmaTransportImpl] Connected to
transport:smtp://Pavel+Denissov@localhost
2005-05-19 23:20:59,749 INFO [STDOUT] DEBUG SMTP: use8bit false
2005-05-19 23:20:59,749 INFO [STDOUT] DEBUG SMTP SENT: MAIL
FROM:<Pavel.Denissov@localhost>
2005-05-19 23:20:59,789 INFO [STDOUT] DEBUG SMTP RCVD: 250
Pavel.Denissov@localhost... Sender OK
2005-05-19 23:20:59,789 INFO [STDOUT] DEBUG SMTP SENT: RCPT
TO:<pavel.denissov@localhost>
2005-05-19 23:20:59,820 INFO [STDOUT] DEBUG SMTP RCVD: 250
pavel.denissov@localhost... Recipient OK
2005-05-19 23:20:59,820 INFO [STDOUT] Verified Addresses
2005-05-19 23:20:59,820 INFO [STDOUT] pavel.denissov@localhost
2005-05-19 23:20:59,820 INFO [STDOUT] DEBUG SMTP SENT: DATA
2005-05-19 23:20:59,850 INFO [STDOUT] DEBUG SMTP RCVD: 354 Enter
message, end with "." on a line by itself
2005-05-19 23:20:59,990 INFO [STDOUT] DEBUG SMTP SENT:=20
.
2005-05-19 23:21:00,060 INFO [STDOUT] DEBUG SMTP RCVD: 250 Message
accepted for delivery
2005-05-19 23:21:00,060 DEBUG
[net.wimpi.webmail.mail.controller.JwmaSession]
removeSessionBean():name=3Dcore_model_composemessage
2005-05-19 23:21:00,070 DEBUG
[net.wimpi.webmail.mail.tags.JwmaSimpleTag] getJwmaSession()
2005-05-19 23:21:00,070 DEBUG
[net.wimpi.webmail.mail.tags.JwmaSimpleTag]
getSessionBean():key=3Dcore_session
2005-05-19 23:21:00,070 INFO [STDOUT] A105 STATUS Inbox (MESSAGES
RECENT UNSEEN UIDNEXT UIDVALIDITY)
2005-05-19 23:21:00,101 INFO [STDOUT] * STATUS Inbox (UIDNEXT 435
UIDVALIDITY 5 MESSAGES 7 RECENT 0 UNSEEN 1)
A105 OK STATUS completed
2005-05-19 23:21:00,101 DEBUG
[net.wimpi.webmail.mail.tags.JwmaSimpleTag] getMessageResources()
2005-05-19 23:21:00,101 DEBUG
[net.wimpi.webmail.mail.tags.JwmaSimpleTag] getSessionLocale()
2005-05-19 23:21:00,101 DEBUG
[net.wimpi.webmail.mail.tags.JwmaSimpleTag]
getSessionBean():key=3Dorg.apache.struts.action.LOCALE
2005-05-19 23:21:00,171 ERROR [org.jboss.web.localhost.Engine]
ApplicationDispatcher[/webmail] Servlet.service() for servlet jsp
threw exception
javax.servlet.jsp.JspException: Cannot find bean
contacts_model_contactgroup in scope request
=09at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:994)
=09at org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:232)
=09at org.apache.jsp.contactgroup_jsp._jspService(contactgroup_jsp.java:100=
8)
=09at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
=09at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
=09at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper=
.java:324)
=09at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:2=
92)
=09at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
=09at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
Regards,=20
--=20
// Pavel
|
|
From: Dieter W. <dwi...@gm...> - 2005-05-19 22:39:05
|
Pavel,
Right, this is a bug that I probably have closed to quickly.
I will re-open it and take a look on how to fix it.
Regards,
Dieter
Pavel Denisov wrote:
> Hi!
>
> I've posted this on the forum, but since sf has really crappy forum support, I'm
> now no longer able to view that forum. So I post it here.
>
> The problem happens when I open up contacts' groups and choose a
> person to mail to. I compose my mail and press send. Then i get this
> stacktrace (not complete, but this seems to be the essensial part).
> I've had this problem before when my contacts-plugin wasn't doing
> stuff right, but now I made sure that every method I've written
> produces a debug-output and I can't see any in the log, so my classes
> aren't even used:
>
>
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.JwmaMultipartRequestHandler] Created
> net.wimpi.webmail.mail.util.JwmaMultipartRequestHandler@faaa93
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.MultipartRequest] Processing request
> data..
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.MultipartRequest] Got Length..
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.MultipartRequest] Got content-type
> (multipart/form-data;
> boundary=---------------------------28228175622324)
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.MultipartRequest] Streaming in...
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.FormdataMultipart] Adding action=send
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.FormdataMultipart] Adding
> to=pavel.denissov@localhost
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.FormdataMultipart] Adding CCTo=
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.FormdataMultipart] Adding BCCTo=
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.FormdataMultipart] Adding subject=Testar
> hmm...
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.FormdataMultipart] Adding body=Haj din
> fisk.
>
> Funkar det här?
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.util.FormdataMultipart] Adding
> mailidentity=jwma-e014e38efd41a6042b1a46c74c81528a
> 2005-05-19 23:20:59,589 DEBUG
> [net.wimpi.webmail.mail.controller.ComposeForm]
> setMailidentity():jwma-e014e38efd41a6042b1a46c74c81528a
> 2005-05-19 23:20:59,609 DEBUG
> [net.wimpi.webmail.mail.controller.ComposeForm] setBody():Haj din
> fisk.
>
> Funkar det här?
> 2005-05-19 23:20:59,609 DEBUG
> [net.wimpi.webmail.mail.controller.JwmaAction]
> net.wimpi.webmail.mail.controller.JwmaSession@18787c9
> 2005-05-19 23:20:59,609 DEBUG
> [net.wimpi.webmail.mail.controller.JwmaSession]
> setActionForm():form=net.wimpi.webmail.mail.controller.ComposeForm@17e72d1
> 2005-05-19 23:20:59,609 DEBUG
> [net.wimpi.webmail.mail.controller.ComposeAction]
> doDispatchActions():action=send
> 2005-05-19 23:20:59,609 DEBUG
> [net.wimpi.webmail.mail.controller.JwmaSession] Stored request bean:{}
> 2005-05-19 23:20:59,609 DEBUG
> [net.wimpi.webmail.mail.model.JwmaComposeMessage] openDraft():is
> draft=false
> 2005-05-19 23:20:59,619 INFO [STDOUT] DEBUG SMTP: useEhlo true, useAuth true
> 2005-05-19 23:20:59,619 INFO [STDOUT]
> DEBUG: SMTPTransport trying to connect to host "172.30.5.33", port 25
> 2005-05-19 23:20:59,699 INFO [STDOUT] DEBUG SMTP RCVD: 220 ESMTP
> Service (Lotus Domino Release 6.5.4) ready at Thu, 19 May 2005
> 23:24:17 +0200
> 2005-05-19 23:20:59,699 INFO [STDOUT] DEBUG: SMTPTransport connected
> to host "172.30.5.33", port: 25
> 2005-05-19 23:20:59,709 INFO [STDOUT] DEBUG SMTP SENT: EHLO pavel
> 2005-05-19 23:20:59,739 INFO [STDOUT] DEBUG SMTP RCVD: 250- Hello
> pavel ([172.30.5.104]), pleased to meet you
> 250-HELP
> 250-SIZE
> 250 PIPELINING
> 2005-05-19 23:20:59,739 INFO [STDOUT] DEBUG SMTP Found extension "HELP", arg ""
> 2005-05-19 23:20:59,739 INFO [STDOUT] DEBUG SMTP Found extension "SIZE", arg ""
> 2005-05-19 23:20:59,739 INFO [STDOUT] DEBUG SMTP Found extension
> "PIPELINING", arg ""
> 2005-05-19 23:20:59,739 DEBUG
> [net.wimpi.webmail.mail.util.JwmaTransportImpl] Connected to
> transport:smtp://Pavel+Denissov@localhost
> 2005-05-19 23:20:59,749 INFO [STDOUT] DEBUG SMTP: use8bit false
> 2005-05-19 23:20:59,749 INFO [STDOUT] DEBUG SMTP SENT: MAIL
> FROM:<Pavel.Denissov@localhost>
> 2005-05-19 23:20:59,789 INFO [STDOUT] DEBUG SMTP RCVD: 250
> Pavel.Denissov@localhost... Sender OK
> 2005-05-19 23:20:59,789 INFO [STDOUT] DEBUG SMTP SENT: RCPT
> TO:<pavel.denissov@localhost>
> 2005-05-19 23:20:59,820 INFO [STDOUT] DEBUG SMTP RCVD: 250
> pavel.denissov@localhost... Recipient OK
> 2005-05-19 23:20:59,820 INFO [STDOUT] Verified Addresses
> 2005-05-19 23:20:59,820 INFO [STDOUT] pavel.denissov@localhost
> 2005-05-19 23:20:59,820 INFO [STDOUT] DEBUG SMTP SENT: DATA
> 2005-05-19 23:20:59,850 INFO [STDOUT] DEBUG SMTP RCVD: 354 Enter
> message, end with "." on a line by itself
> 2005-05-19 23:20:59,990 INFO [STDOUT] DEBUG SMTP SENT:
> .
> 2005-05-19 23:21:00,060 INFO [STDOUT] DEBUG SMTP RCVD: 250 Message
> accepted for delivery
> 2005-05-19 23:21:00,060 DEBUG
> [net.wimpi.webmail.mail.controller.JwmaSession]
> removeSessionBean():name=core_model_composemessage
> 2005-05-19 23:21:00,070 DEBUG
> [net.wimpi.webmail.mail.tags.JwmaSimpleTag] getJwmaSession()
> 2005-05-19 23:21:00,070 DEBUG
> [net.wimpi.webmail.mail.tags.JwmaSimpleTag]
> getSessionBean():key=core_session
> 2005-05-19 23:21:00,070 INFO [STDOUT] A105 STATUS Inbox (MESSAGES
> RECENT UNSEEN UIDNEXT UIDVALIDITY)
> 2005-05-19 23:21:00,101 INFO [STDOUT] * STATUS Inbox (UIDNEXT 435
> UIDVALIDITY 5 MESSAGES 7 RECENT 0 UNSEEN 1)
> A105 OK STATUS completed
> 2005-05-19 23:21:00,101 DEBUG
> [net.wimpi.webmail.mail.tags.JwmaSimpleTag] getMessageResources()
> 2005-05-19 23:21:00,101 DEBUG
> [net.wimpi.webmail.mail.tags.JwmaSimpleTag] getSessionLocale()
> 2005-05-19 23:21:00,101 DEBUG
> [net.wimpi.webmail.mail.tags.JwmaSimpleTag]
> getSessionBean():key=org.apache.struts.action.LOCALE
> 2005-05-19 23:21:00,171 ERROR [org.jboss.web.localhost.Engine]
> ApplicationDispatcher[/webmail] Servlet.service() for servlet jsp
> threw exception
> javax.servlet.jsp.JspException: Cannot find bean
> contacts_model_contactgroup in scope request
> at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:994)
> at org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:232)
> at org.apache.jsp.contactgroup_jsp._jspService(contactgroup_jsp.java:1008)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>
>
> Regards,
|
|
From: Pavel D. <pav...@gm...> - 2005-05-20 06:34:37
|
Good day! Dieter, I have some concerns. I have enabled debugging on everything and while reading the log I see that there is a lot of overhead. Lots of method= s are called several times right after each other and since jwma fetches all = your mail from inbox when you login, there can be quite some action if your inbo= x is large and it takes forever to load. A lot of optimization and maybe cach= ing is needed. Also, for a large inbox, you don't want to fetch all the mails a= t the same time. Imagine an inbox with a couple of hundreds mails and then imagin= e a couple of hundreds users and it isn't fun anymore =3D/ What could be done= is to add "mails per page" setting for each user and only fetch that many mail each time. 20 would be a good default =3D) On 5/20/05, Dieter Wimberger <dwi...@gm...> wrote: > Pavel, >=20 > Right, this is a bug that I probably have closed to quickly. > I will re-open it and take a look on how to fix it. Something I can help with? --=20 // Pavel |
|
From: Dieter W. <dwi...@gm...> - 2005-05-20 14:39:35
|
Pavel, > Dieter, I have some concerns. I have enabled debugging on everything and > while reading the log I see that there is a lot of overhead. Lots of methods > are called several times right after each other Are we talking about repetitive calls that are not required? Might be some bug. > and since jwma fetches all your > mail from inbox when you login, there can be quite some action if your inbox > is large and it takes forever to load. A lot of optimization and maybe caching > is needed. jwma does have some caching mechanisms: 1. Folder list 2. Message list for a folder You might realize that hits on the IMAP server when changing pages are kept as low as possible (basically it should be only the new message count). Atm we are talking about in-memory blow-away cache. Blow-away and because we do not want to keep all folders in cache, just the latest one (so when reading through it, by pages it's quick). Also jwma does use the FetchProfile to specify fetching of the envelope only (for the list). > Also, for a large inbox, you don't want to fetch all the mails at the > same time. Imagine an inbox with a couple of hundreds mails and then imagine > a couple of hundreds users and it isn't fun anymore =/ What could be done is > to add "mails per page" setting for each user and only fetch that many mail > each time. 20 would be a good default =) If you tell me the way to ensure that this works only using the Folder API, then we can give this a try. In general my observation is, that Mail isn't a "lightweight" application. Desktop Mail clients do usually store indices of the message lists in folders and have a hard time keeping them in sync for a single user (or probably two to three). Now imagine a hundred of users ;) Suggestions are welcome. I would first propose to ensure that the "Lots of methods are called several times right after each other" isn't some bug. As a second step we should probably investigate incremental message fetching, where I would say that you need to fetch at least the page length configured by the user (if allowed to do so). We have to be hell careful about the sorting though, this is done by jwma in-memory, so what you see isn't always a consistent index range (which would correspond to the message number, or an incremental fetch by message number). IMAP has extensions for doing server side sorting, but the problem is that we do not have access to these through the standard JavaMail API so far (i.e. these extensions are not standardized and widely in use yet). Third, we can investigate enhancing the cache we have, probably starting to make the Mail client implementation more complicated (adding listeners so that changes on the store are captured and update caches). Fourth, we should also try to make the users understand that having a folder structure instead of 2000 mails in the INBOX would make sense :) Maybe we should pop up some "usage" tips :) Regards, Dieter |
|
From: Pavel D. <pav...@gm...> - 2005-05-20 16:14:06
|
Dieter,=20
> > Dieter, I have some concerns. I have enabled debugging on everything an=
d
> > while reading the log I see that there is a lot of overhead. Lots of me=
thods
> > are called several times right after each other
>=20
> Are we talking about repetitive calls that are not required? Might be
> some bug.
They seem to be repetitive. I have attached a log of the
initialisation and it fetches
lots of stuff several times.
> > and since jwma fetches all your
> > mail from inbox when you login, there can be quite some action if your =
inbox
> > is large and it takes forever to load. A lot of optimization and maybe =
caching
> > is needed.
>
> jwma does have some caching mechanisms:
> 1. Folder list
> 2. Message list for a folder
>=20
> You might realize that hits on the IMAP server when changing pages are
> kept as low as possible (basically it should be only the new message
> count). Atm we are talking about in-memory blow-away cache.
> Blow-away and because we do not want to keep all folders in cache, just
> the latest one (so when reading through it, by pages it's quick).
> Also jwma does use the FetchProfile to specify fetching of the envelope
> only (for the list).
Well, the reason while I mensioned caching was that there were some
repetitive calls
that resulted in imap-requests. A second call to the same function
would not do that
if it used some caching. See the attached log for details.
>=20
> > Also, for a large inbox, you don't want to fetch all the mails at the
> > same time. Imagine an inbox with a couple of hundreds mails and then im=
agine
> > a couple of hundreds users and it isn't fun anymore =3D/ What could be =
done is
> > to add "mails per page" setting for each user and only fetch that many =
mail
> > each time. 20 would be a good default =3D)
>=20
> If you tell me the way to ensure that this works only using the Folder
> API, then we can give this a try.
Well, these functions could probably be used:
abstract Message =09getMessage(int msgnum)
Get the Message object corresponding to the given message number.
abstract int =09getMessageCount()
Get total number of messages in this Folder.
Message[] =09getMessages(int[] msgnums)
Get the Message objects for message numbers specified in the arra=
y.
Message[] =09getMessages(int start, int end)
Get the Message objects for message numbers ranging from
start through end, both start and end inclusive.
> In general my observation is, that Mail isn't a "lightweight"
> application. Desktop Mail clients do usually store indices of the
> message lists in folders and have a hard time keeping them in sync for a
> single user (or probably two to three).
> Now imagine a hundred of users ;)
>
> Suggestions are welcome.
Desktop clients usually handle one user at a time. This application
will be running
online with a lot of users accessing it all the time. If it has to
load a large inbox
every time a user logs in, it will put unnessesary strain on the
server and frustrate
the user, who has to wait "forever".
=20
> I would first propose to ensure that the "Lots of methods
> are called several times right after each other" isn't some bug.
Please see the attached log and judge for yourself. Maybe I'm just
missing something =3D)
> As a second step we should probably investigate incremental message
> fetching, where I would say that you need to fetch at least the page
> length configured by the user (if allowed to do so). We have to be hell
> careful about the sorting though, this is done by jwma in-memory, so
> what you see isn't always a consistent index range (which would
> correspond to the message number, or an incremental fetch by message
> number). IMAP has extensions for doing server side sorting, but the
> problem is that we do not have access to these through the standard
> JavaMail API so far (i.e. these extensions are not standardized and
> widely in use yet).
The sorting shouldn't pose any problem wether you do it in client or
on the server.
Actually, I think doing it on the client is the better way, since all
you are doing is
changing the representation without affecting data. All you'd have to do is=
to
provide a means of conversion between in-client stored message indexes and=
=20
server stored message indexes.
>=20
> Third, we can investigate enhancing the cache we have, probably starting
> to make the Mail client implementation more complicated (adding
> listeners so that changes on the store are captured and update caches).
Actually, if the ev. bug with repetitive method calls is solved and
the incremental
message fetching is implemented, caching should be less of a problem. In
certain environments it would be possible to do "live" operations. Maybe
caching should be a setting you can change? =3D)
> Fourth, we should also try to make the users understand that having a
> folder structure instead of 2000 mails in the INBOX would make sense :)
> Maybe we should pop up some "usage" tips :)
Well, that's how users are. Giving them tips and hints is all for the
better, but you
still have to design for the worst-case scenario, because it will
happen none-the-less.
A good application should adopt itself to the user, not the other way aroun=
d
(with certain exceptions, ofcourse =3D).
I have removed the attached file because I realised that sending attachemen=
ts to
a list is not polite. It is available at
http://katja.mine.nu/~storm/jwmalog1.txt instead.
Cheers!
--=20
// Pavel
|
|
From: Dieter W. <dwi...@gm...> - 2005-05-20 20:54:32
|
Pavel,
> They seem to be repetitive. I have attached a log of the
> initialisation and it fetches
> lots of stuff several times.
I will try to interpret your log:
1.)
[...]
2005-05-20 17:24:01,385 DEBUG
[net.wimpi.webmail.mail.model.JwmaStoreImpl] prepare()
2005-05-20 17:24:01,525 INFO [STDOUT] A2 LIST "" ""
2005-05-20 17:24:01,525 INFO [STDOUT] * LIST (\Noselect) "\\" ""
A2 OK LIST completed
2005-05-20 17:24:01,545 DEBUG
[net.wimpi.webmail.mail.model.JwmaStoreImpl] Prepare set root folder to:
[...]
This is the JavaMail API trying to obtain the default folder from your
server, as none has been or can be configured.
2.)
[...]
2005-05-20 17:24:01,555 DEBUG
[net.wimpi.webmail.mail.model.JwmaFolderList] rebuild()
2005-05-20 17:24:01,555 INFO [STDOUT] A3 LIST "" "*"
2005-05-20 17:24:01,555 INFO [STDOUT] * LIST (\HasNoChildren) "\\"
123reporting
* LIST (\HasNoChildren) "\\" Apa
* LIST (\HasNoChildren) "\\" Draft
* LIST (\HasNoChildren) "\\" email
* LIST (\HasNoChildren) "\\" external
* LIST (\Noinferiors \HasNoChildren) "\\" Inbox
* LIST (\HasNoChildren) "\\" Other
* LIST (\HasNoChildren) "\\" PDispatch
* LIST (\HasNoChildren) "\\" Personal
* LIST (\HasNoChildren) "\\" SDI-UTV
* LIST (\Noinferiors \HasNoChildren) "\\" Trash
A3 OK LIST completed
[..]
[...]
2005-05-20 17:24:01,555 INFO [STDOUT] A4 LSUB "" 123reporting
2005-05-20 17:24:01,555 INFO [STDOUT] A4 OK LSUB completed
2005-05-20 17:24:01,555 DEBUG
[net.wimpi.webmail.mail.model.JwmaFolderImpl] createLight(): new folder
123reporting:123reporting
[... for each folder]
This is the list of all the stores folders that we cache within jwma for
operations like moving folders and messages. Each instance of a
lightweight folder holds: Name, Path, Type and Subscription Status.
3.)
[...]
2005-05-20 17:24:01,586 INFO [STDOUT] A15 LIST INBOX ""
2005-05-20 17:24:01,586 INFO [STDOUT] * LIST (\Noselect) "\\" ""
A15 OK LIST completed
2005-05-20 17:24:01,586 INFO [STDOUT] A16 LIST "" INBOX
2005-05-20 17:24:01,586 INFO [STDOUT] * LIST (\Noinferiors
\HasNoChildren) "\\" Inbox
A16 OK LIST completed
2005-05-20 17:24:01,586 INFO [STDOUT] A17 LSUB "" Inbox
2005-05-20 17:24:01,596 INFO [STDOUT] A17 OK LSUB completed
2005-05-20 17:24:01,596 DEBUG
[net.wimpi.webmail.mail.model.JwmaFolderList] rebuild()
2005-05-20 17:24:01,596 DEBUG
[net.wimpi.webmail.mail.model.JwmaFolderList]
createSubfolderList(Folder):net.wimpi.webmail.mail.model.JwmaFolderList@16ac92e
path=Inbox
2005-05-20 17:24:01,596 INFO [STDOUT] DEBUG: connection available --
size: 1
2005-05-20 17:24:01,596 INFO [STDOUT] A18 EXAMINE Inbox
2005-05-20 17:24:01,606 INFO [STDOUT] * 7 EXISTS
[...]
This block, plus much of what follows is to prepare the INBOX list (it
might be as well a mixed Folder!) and it's message list cache.
Envelopes are fetched subsequently for each message.
4.)
[...]
2005-05-20 17:24:02,428 INFO [STDOUT] A36 SUBSCRIBE Trash
2005-05-20 17:24:02,428 INFO [STDOUT] A36 OK SUBSCRIBE completed
2005-05-20 17:24:02,428 INFO [STDOUT] A37 LSUB "" Trash
2005-05-20 17:24:02,428 INFO [STDOUT] * LSUB () "\\" Trash
A37 OK LSUB completed
2005-05-20 17:24:02,428 DEBUG
[net.wimpi.webmail.mail.model.JwmaFolderImpl] createLight(): new folder
Trash:Trash
2005-05-20 17:24:02,428 INFO [STDOUT] A38 LIST "" Draft
2005-05-20 17:24:02,438 INFO [STDOUT] * LIST (\HasNoChildren) "\\" Draft
A38 OK LIST completed
2005-05-20 17:24:02,438 INFO [STDOUT] A39 SUBSCRIBE Draft
2005-05-20 17:24:02,438 INFO [STDOUT] A39 OK SUBSCRIBE completed
2005-05-20 17:24:02,438 INFO [STDOUT] A40 LSUB "" ""
2005-05-20 17:24:02,438 INFO [STDOUT] A40 OK LSUB completed
[...]
This seems to be caused by preparing a trash folder and the draft
folder. Why it has "SUBSCRIBE"s there, I don't know.
5.)
The next block seems to be a problem right.
It might be caused by:
//store JwmaFolderImpl of root as last, to set the actual folder
//to root
m_JwmaRootFolder = getJwmaFolder(m_RootFolder.getFullName());
Ok...here I think we pinned down something that could be an issue.
I will take a look at this ASAP. I think it is caused by the fact that
in the login() Action I do this:
JwmaStoreImpl store = session.getJwmaStore();
//log.debug("Have Store!");
store.setActualFolder("INBOX");
Which likely is not a good idea and could cause what you see in the log.
I will investigate the issue and keep track of it with a corresponding bug.
6.) All the LDAP Service block is yours.
> Well, the reason while I mensioned caching was that there were some
> repetitive calls
> that resulted in imap-requests. A second call to the same function
> would not do that
> if it used some caching. See the attached log for details.
I think it is a bug or simply a bad workaround for making the INBOX the
first folder a user is forwarded to on login.
> Well, these functions could probably be used:
>
> abstract Message getMessage(int msgnum)
> Get the Message object corresponding to the given message number.
> abstract int getMessageCount()
> Get total number of messages in this Folder.
> Message[] getMessages(int[] msgnums)
> Get the Message objects for message numbers specified in the array.
> Message[] getMessages(int start, int end)
> Get the Message objects for message numbers ranging from
> start through end, both start and end inclusive.
Right but here is the issue with the sort.
If one offers sorting capabilities in the IMAP client side (2nd tier in
jwma, happens on the web application server), its _IMPOSSIBLE_ to fetch
in "batches" because you simply have no way to decide which msgnums you
need to fetch.....
Think about it :) You can't sort on criterias you don't have any values
for yet.
> Desktop clients usually handle one user at a time. This application
> will be running
> online with a lot of users accessing it all the time. If it has to
> load a large inbox
> every time a user logs in, it will put unnessesary strain on the
> server and frustrate
> the user, who has to wait "forever".
I think that for large sites the only choice is to use a powerful server
system (with the IMAP running on a separate node) and probably to do
round robin dns balancing to more than one web application server.
jwma has ended up in many products of IT companies, I am sure they found
some way to use it properly for a large amount of users.
>>I would first propose to ensure that the "Lots of methods
>>are called several times right after each other" isn't some bug.
>
>
> Please see the attached log and judge for yourself. Maybe I'm just
> missing something =)
Done. I think we have traced down a bug in the way the system is
prepared on startup. Fixing this should remove some of the time at startup.
>>As a second step we should probably investigate incremental message
>>fetching, where I would say that you need to fetch at least the page
>>length configured by the user (if allowed to do so). We have to be hell
>>careful about the sorting though, this is done by jwma in-memory, so
>>what you see isn't always a consistent index range (which would
>>correspond to the message number, or an incremental fetch by message
>>number). IMAP has extensions for doing server side sorting, but the
>>problem is that we do not have access to these through the standard
>>JavaMail API so far (i.e. these extensions are not standardized and
>>widely in use yet).
>
>
> The sorting shouldn't pose any problem wether you do it in client or
> on the server.
> Actually, I think doing it on the client is the better way, since all
> you are doing is
> changing the representation without affecting data. All you'd have to do is to
> provide a means of conversion between in-client stored message indexes and
> server stored message indexes.
See above. The sorting poses a problem, because you sort by a criteria,
and you need to have values for the criteria you want to sort for.
There is simply no way to establish this "conversion", except you can
adivinate what indices a sort by a criteria (that you don't know values
of) would yield to fetch them in batches.
I am into computer sciences, not the adivination business, I can't ;)
>>Third, we can investigate enhancing the cache we have, probably starting
>>to make the Mail client implementation more complicated (adding
>>listeners so that changes on the store are captured and update caches).
>
>
> Actually, if the ev. bug with repetitive method calls is solved and
> the incremental
> message fetching is implemented, caching should be less of a problem. In
> certain environments it would be possible to do "live" operations. Maybe
> caching should be a setting you can change? =)
We have a very conservative implementation of the message list cache.
Its based on following simple rules:
1. A change in the message count blows away the cache, if not caused
through jwma.
(Deletes and moves through the jwma controller are traced through the
cache mechanism).
2. A change of the folder blows away the cache
This is helpful when paging through message lists and performing message
based actions (moves, deletes, replies etc.)
The point where we could probably enhance the cache is the INBOX.
If new mail arrives, the cache is blown away. Probably we can
investigate this issue to see whether we can provide a deterministic
update for the cache.
> Well, that's how users are. Giving them tips and hints is all for the
> better, but you
> still have to design for the worst-case scenario, because it will
> happen none-the-less.
> A good application should adopt itself to the user, not the other way around
> (with certain exceptions, ofcourse =).
Well this is true when you do use-case based design. We are trying to
atm. but fact is that there is no single unique use case for mail
clients in general (that's also the reason why there are so many and why
they are so feature loaded).
The real challenge is to find a balance between Features and
Performance. Some "simple features" often result difficult to realize
without performance drawbacks (see sorting). The critical part here is
that the range of uses for webmail are wide, between single machine
installations for home networks and large business systems there is
quite anything to be found. Our codebase has ended up in both, although
probably not much was returned to the original project, at least we know
that it isn't the worst codebase out there and that it has been selected
and used even by large IT and Logistics companies as a starting point.
And: last but not least we are an Open Source Project functioning by
Meritocracy. The developer community will decide where we will be
tomorrow ;)
> I have removed the attached file because I realised that sending attachements to
> a list is not polite. It is available at
> http://katja.mine.nu/~storm/jwmalog1.txt instead.
Correct. I have fetched it from there and commented it above. I think it
was of help to trace down what could be a possible bug.
Regards,
Dieter
|
|
From: Pavel D. <pav...@gm...> - 2005-05-21 12:20:30
|
Dieter, > Which likely is not a good idea and could cause what you see in the log. > I will investigate the issue and keep track of it with a corresponding bu= g. Ah I see... Great =3D) >=20 > > Well, these functions could probably be used: > > > > abstract Message getMessage(int msgnum) > > Get the Message object corresponding to the given message num= ber. > > abstract int getMessageCount() > > Get total number of messages in this Folder. > > Message[] getMessages(int[] msgnums) > > Get the Message objects for message numbers specified in the = array. > > Message[] getMessages(int start, int end) > > Get the Message objects for message numbers ranging from > > start through end, both start and end inclusive. >=20 > Right but here is the issue with the sort. > If one offers sorting capabilities in the IMAP client side (2nd tier in > jwma, happens on the web application server), its _IMPOSSIBLE_ to fetch > in "batches" because you simply have no way to decide which msgnums you > need to fetch..... > Think about it :) You can't sort on criterias you don't have any values > for yet. Right. So what we have is a server that numbers messages in some unspecifie= d but consistent order. To display these messages we have to use some sort of sorting. To be able to sort them, we must have all messages, unless the sor= ting method should be the same as the servers (but we don't know that). At the moment, this certainly seems an unsolvable problem. My question then is: should you fetch all messages and sort them at the log= in? I really don't like the idea that the user has to wait a long time just to login. There should be a login-operation and there should be a view folder-operati= on. If the first action after login is view folder, then ok, so be it, but that should be a setting and in the current implementation I believe you are taken to the setting page at first (or is it just for new users? I'm restarting the server all the time so the settings are lost after each login). This gives the impression that log= in in takes forever while viewing folders is instant. > I think that for large sites the only choice is to use a powerful server > system (with the IMAP running on a separate node) and probably to do > round robin dns balancing to more than one web application server. >=20 > jwma has ended up in many products of IT companies, I am sure they found > some way to use it properly for a large amount of users. Ofcourse, you can always add more hardware. But is that a good solution? If a small improvement will mean that you have to buy less servers, why not do it? > Done. I think we have traced down a bug in the way the system is > prepared on startup. Fixing this should remove some of the time at startu= p. Splendid! =3D) =20 > We have a very conservative implementation of the message list cache. > Its based on following simple rules: >=20 > 1. A change in the message count blows away the cache, if not caused > through jwma. > (Deletes and moves through the jwma controller are traced through the > cache mechanism). >=20 > 2. A change of the folder blows away the cache >=20 > This is helpful when paging through message lists and performing message > based actions (moves, deletes, replies etc.) >=20 > The point where we could probably enhance the cache is the INBOX. > If new mail arrives, the cache is blown away. Probably we can > investigate this issue to see whether we can provide a deterministic > update for the cache. Ok, thanks for the explanation. Seems you're on top of this =3D) > Well this is true when you do use-case based design. We are trying to > atm. but fact is that there is no single unique use case for mail > clients in general (that's also the reason why there are so many and why > they are so feature loaded). Really? I though you used mail-clients for reading mail. You login, see if there's any new mail, ev. read it, reply, log out. Isn't that a typical use-case? At least that's how I use mail myself. With IMAP you have some atoms (a folder, a message) and you can perform actions on these atoms (read, expunge, delete,...). In the client you introduce more atoms (a contact, a contactgroup, sorting criteria...) with more actions you can perform on these atoms. Finally you have a system-wide acti= on of login / logout. Writing out all these atoms and actions in a diagram (state perhaps?) you'll be able to generate many use-cases (and test-cases). Or are you talk= ing about something else? > The real challenge is to find a balance between Features and > Performance. Some "simple features" often result difficult to realize > without performance drawbacks (see sorting). The critical part here is > that the range of uses for webmail are wide, between single machine > installations for home networks and large business systems there is > quite anything to be found. Our codebase has ended up in both, although > probably not much was returned to the original project, at least we know > that it isn't the worst codebase out there and that it has been selected > and used even by large IT and Logistics companies as a starting point. Why do you think I'm using jwma as well? =3D) But being good doesn't mean you can't be better. Improvement is always good, don't you think? What I'm trying is to raise a discussion about things I think can be improved. If yo= u disagree, at least you'll have an official reason and if you agree then... = let's start improving =3D) The balance between Features and Performance is always an issue. I love features, but you can't live without good performance. I'm of the opinion t= hat every piece of technology is to HELP a user perform a task, ie it is a tool= . The perfect tool does its job while being completely transparent to the use= r. Now there's no perfect tool, but that's no argument for not using a better = tool. In case of the feature/performance-issue, I believe you should develop with= both in mind and not lock the user in. If there is a descision needs to be done, leave an option to change it for the user. For instance if a user wants to disable sorting to improve performance, it should be possible. > And: last but not least we are an Open Source Project functioning by > Meritocracy. The developer community will decide where we will be > tomorrow ;) Well, I'm on the developer-mailinglist so... =3D) By the way, I'm a student of CS at a university in Sweden. And while I'm into the computer-part, I'm not really into science. For instance, I'll take my masters but have no plans on staying in the university. I am very aware of user-friendliness and have gotten into quality assurance lately. Both are very exciting subjects, I think. I would like to contribute to this project as much as I can, if not with good code then with discussions and evaluation =3D) And the reason I've got into this project is that I am to deploy it in the company I work for. I'll be integrating it into our web-framework (doing a new view) and making sure it works with our imap and ldap servers in the way we want. The users will be simple people, not always IT-educated, so user-experience is an important factor. The amount of users we will have is about 100-500 so performance can be a factor as well. Thanks for the great support, btw! Your help and presence was one of the deciding factors for using this project =3D) Cheers! --=20 // Pavel |
|
From: Dieter W. <dwi...@gm...> - 2005-05-21 14:25:33
|
Pavel, > Right. So what we have is a server that numbers messages in some unspecified > but consistent order. To display these messages we have to use some sort of > sorting. To be able to sort them, we must have all messages, unless the sorting > method should be the same as the servers (but we don't know that). At the > moment, this certainly seems an unsolvable problem. The problem is related also to the fact that each user can select his preferred sort and that it is stored in the users preferences. The solution to this problem could be message fetching against a server side sort, so we could fetch pre-sorted batches (i.e. "give me the first twenty by date"). > My question then is: should you fetch all messages and sort them at the login? > I really don't like the idea that the user has to wait a long time > just to login. Formerly the users where taken to the root folder. We have changed this on request, giving in to the argumentation that users want to see their new mail first. Another reason is that in many IMAP Servers the root is the INBOX (in your case?) and it likely contains folders and the INBOX messages..... > There should be a login-operation and there should be a view folder-operation. > If the first action after login is view folder, then ok, so be it, but > that should be > a setting and in the current implementation I believe you are taken to > the setting > page at first (or is it just for new users? I'm restarting the server > all the time so > the settings are lost after each login). This gives the impression that login in > takes forever while viewing folders is instant. At the moment the user is taken to the settings page only at the first login. However, the way it is done it probably takes the same time (I have to check, it's related to the bug I have reported). At the rest of the logins, the user is taken to the INBOX at the moment, this we could probably make configurable, but WHERE do you want the user to end up? Also don't forget that you should "benchmark" this with: 1. all the logging deactivated (at the moment you have the complete conversation log and all the webapp logging) 2. Compilation with optimization >>I think that for large sites the only choice is to use a powerful server >>system (with the IMAP running on a separate node) and probably to do >>round robin dns balancing to more than one web application server. >> >>jwma has ended up in many products of IT companies, I am sure they found >>some way to use it properly for a large amount of users. > > > Ofcourse, you can always add more hardware. But is that a good solution? > If a small improvement will mean that you have to buy less servers, why > not do it? We will try to improve as much as we can. I am not saying that everything has to be solved by hardware, I just say it that the boundaries on "small improvements" are often not so small ;) Also, what would you really propose as a "small improvement"? Remove the client side sorting? Add another View where we send the user to on login? > Ok, thanks for the explanation. Seems you're on top of this =) You are welcome. >>Well this is true when you do use-case based design. We are trying to >>atm. but fact is that there is no single unique use case for mail >>clients in general (that's also the reason why there are so many and why >>they are so feature loaded). > Really? I though you used mail-clients for reading mail. You login, > see if there's > any new mail, ev. read it, reply, log out. Isn't that a typical > use-case? At least > that's how I use mail myself. With IMAP you have some atoms (a folder, > a message) > and you can perform actions on these atoms (read, expunge, > delete,...). In the client > you introduce more atoms (a contact, a contactgroup, sorting > criteria...) with more > actions you can perform on these atoms. Finally you have a system-wide action of > login / logout. Writing out all these atoms and actions in a diagram > (state perhaps?) > you'll be able to generate many use-cases (and test-cases). Or are you talking > about something else? Well, why do you think there is Eudora, Outlook, Outlook Express, Entourage, Apple Mail, Thunderbird, Pegasus..... SquirrelMail, OpenWebmail, jwebmail, GatorMail, jwma, IMP etc. etc. wc. There are many, really. Sure you have a base use case, but then it comes to the features that make the user select one or the other. I also just read my mail, but somebody else wants to read HTML Mail and see the smileys as images etc. The other wants the perfect address book that does all imports and exports and if possible automatically updates the Palm and the cellular phone database automagically. I thought it would be as simple when I kicked off this project, but well :) Experience over the time (it's quite some years now) has tought me that it's not as simple as I thought. > Why do you think I'm using jwma as well? =) But being good doesn't mean > you can't be better. Improvement is always good, don't you think? What I'm > trying is to raise a discussion about things I think can be improved. If you > disagree, at least you'll have an official reason and if you agree then... let's > start improving =) Great, that's what we are looking for :) I'm also just discussing the improvements, trying to make transparent what is the problem behind a probably "simple" looking improvement. We will try to do our best. You are welcome also to help and figure out how to do so. I would also like to point out that there is much to be done that isn't code. An FAQ compiled from the projects resources (mailing list archives, foras etc.) would be great for example, or the documentation migration (which I am doing a little bit sometimes) etc. The new UI design, which I have kicked off, but it's a completely knew domain for me. I would rather spend time on the code, if there are helping hands :) But here we go, the Bugs are in and I am working on them, so we will improve something :) > Well, I'm on the developer-mailinglist so... =) That's great, you have started to shape the future ;) > By the way, I'm a student of CS at a university in Sweden. And while > I'm into the > computer-part, I'm not really into science. For instance, I'll take my > masters but > have no plans on staying in the university. I am very aware of > user-friendliness and > have gotten into quality assurance lately. Both are very exciting > subjects, I think. > I would like to contribute to this project as much as I can, if not > with good code then > with discussions and evaluation =) Right. I am at the UNAM, doing a PhD in Computer Sciences and Engineering. I am actually into doing a supervision and monitoring system for a batch wastewater treatment reactor. Originally I have been studying Petroleum Engineering and got a lot into Computers and Automation ;) Unfortunately time is a precious resource at the moment...some helping hands (hands on) would be good. All your evaluations will be traced, we might take a little while to bring it into existence though, except you decide for a "hands on" approach. How about HTML-> Apache Docbook conversion of the old docs? Or some User Interface work? If you are into usability, probably this would be a good thing. > And the reason I've got into this project is that I am to deploy it in > the company > I work for. I'll be integrating it into our web-framework (doing a new > view) and making > sure it works with our imap and ldap servers in the way we want. > The users will be simple people, not always IT-educated, so > user-experience is an > important factor. The amount of users we will have is about 100-500 so > performance > can be a factor as well. I see. Probably Leonard can give us an idea on how many users are using jwma at NCAR/UCAR and what the required infrastructure is. We are working on a new view as well. I don't know if you would be interested to do some hands on with this one, but fact is that it's about a clean separation of structure+content (XHMTL) and layout (CSS), that should make it easy to adapt the view for the look preferred (adapting or rewriting the CSS). It would be great to push this one as much as possible, probably we are able to achieve some synergy here? So that work flows into your job and back into the jwma project at the same time? > Thanks for the great support, btw! Your help and presence was one of > the deciding > factors for using this project =) You are welcome. We are trying to improve, the biggest obstacle atm is probably the work load. As I am doing most of the direct hands on, it's my work load, so probably my responses feel "time-biased" sometimes, despite the fact that the critics were constructive and improvements suggested. Thank you for your time, too :) Best Regards, Dieter |
|
From: Pavel D. <pav...@gm...> - 2005-05-22 09:34:33
|
Gosh, the mails are getting longer and longer, that's probably a good sign = =3D) > The problem is related also to the fact that each user can select his > preferred sort and that it is stored in the users preferences. > The solution to this problem could be message fetching against a server > side sort, so we could fetch pre-sorted batches (i.e. "give me the first > twenty by date"). Yes, if that can be done, it'd be good. But as you said, API doesn't allow = it. And I think it is good to stick with the api, since it will ensure compatibility. > Formerly the users where taken to the root folder. We have changed this > on request, giving in to the argumentation that users want to see their > new mail first. > Another reason is that in many IMAP Servers the root is the INBOX (in > your case?) and it likely contains folders and the INBOX messages..... Ah yes, good point. Hmm... I'll think this over. > > There should be a login-operation and there should be a view folder-ope= ration. > > If the first action after login is view folder, then ok, so be it, but > > that should be > > a setting and in the current implementation I believe you are taken to > > the setting > > page at first (or is it just for new users? I'm restarting the server > > all the time so > > the settings are lost after each login). This gives the impression that= login in > > takes forever while viewing folders is instant. >=20 > At the moment the user is taken to the settings page only at the first > login. However, the way it is done it probably takes the same time (I > have to check, it's related to the bug I have reported). Well that's what I wondered, since all the fetching and loading is done any= way. In my case the root folder is Inbox so changing that wouldn't do anything. > At the rest of the logins, the user is taken to the INBOX at the moment, > this we could probably make configurable, but WHERE do you want the > user to end up? It's good to make it configurable, but you are right that most users will want to check new mail first so inbox is a logical place to go. But as I said, I'll think about this. > Also don't forget that you should "benchmark" this with: > 1. all the logging deactivated (at the moment you have the complete > conversation log and all the webapp logging) > 2. Compilation with optimization Ah yes, ofcourse. That will definetely speed things up. But it is interesting to do testing and developing in "worst case"-scenario, then you'll know that your app will always perform better than this. =3D) > Also, what would you really propose as a "small improvement"? > Remove the client side sorting? > Add another View where we send the user to on login? I was speaking generally and mostly refering to your statement that more hardware may solve the problem. My point was also that a small improvement (an order of say, optimising a single method) might mean a lot when scaling up. =20 > Well, why do you think there is > Eudora, Outlook, Outlook Express, Entourage, Apple Mail, Thunderbird, > Pegasus..... > SquirrelMail, OpenWebmail, jwebmail, GatorMail, jwma, IMP etc. etc. wc. >=20 > There are many, really. Sure you have a base use case, but then it comes > to the features that make the user select one or the other. >=20 > I also just read my mail, but somebody else wants to read HTML Mail and > see the smileys as images etc. The other wants the perfect address book > that does all imports and exports and if possible automatically updates > the Palm and the cellular phone database automagically. >=20 > I thought it would be as simple when I kicked off this project, but well > :) Experience over the time (it's quite some years now) has tought me > that it's not as simple as I thought. You are right. This is something that I've witnessed in many areas, not only software. Feature-bloating is a horrible thing. It puts focus on the tool instead of the job. I've already told you about my views on the tool. It should have basic functionality that it excells at. When adding more features care should be taken not to make the original functionality worse and in any case make that feature configurable so that in the worst case a user can shut it off. I'm quite fond of smilies (as you can see =3D) but if I am to send an email with some code for example, I don't want to to become garbage at the other end, so i want to be able to turn off smilies at some times. The important thing is to have a focus on something and keep that focus. For instance you could have focus on a pretty user-interface, or lots of features. I'd s= ay jwmas focus seems to be simplicity and design. At least that's what I like about it =3D) If you have a good design to start with, adding features is easy if you would want to. > We are working on a new view as well. I don't know if you would be > interested to do some hands on with this one, but fact is that it's > about a clean separation of structure+content (XHMTL) and layout (CSS), > that should make it easy to adapt the view for the look preferred > (adapting or rewriting the CSS). Beautiful! That is what I would want in the first place. I've been into webdesign a bit but got dissapointed with css, since it didn't work crossbrowser. But= now it is good enough to enable good content/layout separation that works well in most cases. Do you have that view somewhere in cvs perhaps? =3D) > > Thanks for the great support, btw! Your help and presence was one of > > the deciding > > factors for using this project =3D) >=20 > You are welcome. We are trying to improve, the biggest obstacle atm is > probably the work load. As I am doing most of the direct hands on, it's > my work load, so probably my responses feel "time-biased" sometimes, > despite the fact that the critics were constructive and improvements > suggested. Time is always THE factor, right? With school at 100% and work at 50% I am not too spoiled by that either. I wish I didn't have to sleep =3DP > Thank you for your time, too :) You're welcome! Just happy to participate =3D) Cheers! --=20 // Pavel |
|
From: Dieter W. <dwi...@gm...> - 2005-05-22 16:21:51
|
Pavel, >>Formerly the users where taken to the root folder. We have changed this >>on request, giving in to the argumentation that users want to see their >>new mail first. >>Another reason is that in many IMAP Servers the root is the INBOX (in >>your case?) and it likely contains folders and the INBOX messages..... > > > Ah yes, good point. Hmm... I'll think this over. If you have any good idea it's welcome. An idea that I have is to add something like a welcome page with a possible Admin message or news (motd like; this was requested by Leonard once) and just show a Inbox state summary (so much new messages out of so much). What do you think? Leonard: What's your opinion about this one? > Well that's what I wondered, since all the fetching and loading is done anyway. > In my case the root folder is Inbox so changing that wouldn't do anything. Not really, from your logs it seems rather to be an empty or null root, that holds folders and your INBOX. > It's good to make it configurable, but you are right that most users > will want to > check new mail first so inbox is a logical place to go. But as I said, > I'll think about > this. See above. >>Also don't forget that you should "benchmark" this with: >>1. all the logging deactivated (at the moment you have the complete >>conversation log and all the webapp logging) >>2. Compilation with optimization > > > Ah yes, ofcourse. That will definetely speed things up. But it is > interesting to do testing > and developing in "worst case"-scenario, then you'll know that your > app will always perform better than this. =) That's ok :) > I was speaking generally and mostly refering to your statement that > more hardware > may solve the problem. My point was also that a small improvement (an > order of say, > optimising a single method) might mean a lot when scaling up. Improvement in progress, I have already fixed the issue and will commit it asap with a lot of other fixes I have introduced working down the still open bug list. > You are right. This is something that I've witnessed in many areas, > not only software. > Feature-bloating is a horrible thing. It puts focus on the tool > instead of the job. > I've already told you about my views on the tool. It should have basic > functionality > that it excells at. When adding more features care should be taken not > to make the > original functionality worse and in any case make that feature > configurable so that > in the worst case a user can shut it off. I'm quite fond of smilies > (as you can see =) Configuration is one of the things that can be bloated quickly too. With all the configurable features jwma already has, it is getting more and more difficult to get admins started deploying jwma. You have no idea how many email and angry feedback I received because it doesn't work out of the box. It's no toy any longer ;) You can have your smileys. What it takes is a jtextproc filter and new filter chains. These could be used to translate known smileys into images (:) to <img/>). Filter chains can be selected by the user in the settings. See jtextproc ..... > but if I am to send an email with some code for example, I don't want > to to become > garbage at the other end, so i want to be able to turn off smilies at > some times. > > The important thing is to have a focus on something and keep that > focus. For instance > you could have focus on a pretty user-interface, or lots of features. I'd say > jwmas focus seems to be simplicity and design. At least that's what I > like about it =) > If you have a good design to start with, adding features is easy if > you would want to. I think we have already bloated it a lot since the beginnning. But well it was mainly community driven :) I would indeed say that we continue with simplicity and design. One of the important points is a fully XHMTL 1.0 Strict and CSS (W3C validated) User interface (Again, no clue how many people sent me angry mail because of the black/grey view; even though I always insist it's just one example, adapt it!). Now the idea is to make it completely adaptable as CSS, and to try and make adaptation possible for a web designer. >>We are working on a new view as well. I don't know if you would be >>interested to do some hands on with this one, but fact is that it's >>about a clean separation of structure+content (XHMTL) and layout (CSS), >>that should make it easy to adapt the view for the look preferred >>(adapting or rewriting the CSS). > > > Beautiful! That is what I would want in the first place. I've been > into webdesign > a bit but got dissapointed with css, since it didn't work crossbrowser. But now > it is good enough to enable good content/layout separation that works well > in most cases. Do you have that view somewhere in cvs perhaps? =) No it is not in CVS. The whole thing is starting as a Wireframe, it's not yet a view, but rather a static "dummy" of what the view could become one day. If you are interested in this approach, I can make the wireframe available to you. > Time is always THE factor, right? With school at 100% and work at 50% I am > not too spoiled by that either. I wish I didn't have to sleep =P My record is 52 hours, most of the time spend hacking, until the end :) But now I have family and grew older..... ;) > You're welcome! Just happy to participate =) Great. Regards, Dieter |
|
From: Leonard S. <sit...@uc...> - 2005-05-23 17:18:38
|
On May 22, 2005, at 10:21 AM, Dieter Wimberger wrote: > > >>> Formerly the users where taken to the root folder. We have >>> changed this >>> on request, giving in to the argumentation that users want to see >>> their >>> new mail first. >>> Another reason is that in many IMAP Servers the root is the INBOX >>> (in >>> your case?) and it likely contains folders and the INBOX >>> messages..... >>> >> Ah yes, good point. Hmm... I'll think this over. >> > > If you have any good idea it's welcome. An idea that I have is to > add something like a welcome page with a possible Admin message or > news (motd like; this was requested by Leonard once) and just show > a Inbox state summary (so much new messages out of so much). > > What do you think? > Leonard: What's your opinion about this one? > > I think the majority of users will want to read new mail immediately, so the list of messages in the inbox should be shown first at login. I think a motd would be a nice feature. I don't know what the best UI for that would be. Login -> motd (display for N seconds, then automatically forward) -> inbox? Display on the login page along with login/password input fields? Display on login page but remove post first action? ==Leonard |
|
From: Leonard S. <sit...@uc...> - 2005-05-23 17:20:43
|
On May 22, 2005, at 10:21 AM, Dieter Wimberger wrote: > If you are interested in this approach, I can make the wireframe > available to you. > I, too, think it would be wonderful if you are interested in contributing to this, Pavel. ==Leonard |
|
From: Pavel D. <pav...@gm...> - 2005-05-23 19:34:07
|
Hello, Dieter and Leonard! > I think the majority of users will want to read new mail immediately, > so the list of messages in the inbox should be shown first at login. >=20 > I think a motd would be a nice feature. I don't know what the best > UI for that would be. Login -> motd (display for N seconds, then > automatically forward) -> inbox? Display on the login page along > with login/password input fields? Display on login page but remove > post first action? Why not put motd on top of the inbox? A whole page for motd seems a bit overkill. In any case it is something a user should be able to disabl= e. In fact, this can be a rather complex subject, since you want someone to administer this in an easy fascion (not having to restart the server, that is). > > If you are interested in this approach, I can make the wireframe > > available to you. > > >=20 > I, too, think it would be wonderful if you are interested in > contributing to this, Pavel. Well that makes two of us =3D) So where can I get this wireframe of yours? Cheers! --=20 // Pavel |
|
From: Dieter W. <dwi...@gm...> - 2005-05-23 20:27:49
|
Pavel, >>I think a motd would be a nice feature. I don't know what the best >>UI for that would be. Login -> motd (display for N seconds, then >>automatically forward) -> inbox? Display on the login page along >>with login/password input fields? Display on login page but remove >>post first action? > > Why not put motd on top of the inbox? A whole page for motd seems > a bit overkill. I think it could be a simple message box as envisioned for the new UI. This way it would appear on top of the first page, no matter what that first page will be. >In any case it is something a user should be able to disable. > In fact, this can be a rather complex subject, since you want someone > to administer this in an easy fascion (not having to restart the > server, that is). I think this is the more complicated part, although we can select a level of complexity. The question is if the user should see it only once (even if he logs in more than once the same day), because then it would become more complicated, given that we need to keep track on who has seen it already and who has not. Else it isn't so complicated either, for a start we could just add a mechanism that reads it from somewhere (could be an URL) every n timeunits to keep it in memory for quick displaying and add it as message in the login() SessionAction. > >>>If you are interested in this approach, I can make the wireframe >>>available to you. >>> >> >>I, too, think it would be wonderful if you are interested in >>contributing to this, Pavel. > > > Well that makes two of us =) So where can I get this wireframe of yours? I'll put it together and mail it to you ASAP. Regards, Dieter |
|
From: Leonard S. <sit...@uc...> - 2005-05-23 17:11:00
|
On May 21, 2005, at 8:25 AM, Dieter Wimberger wrote:
>
>
>> And the reason I've got into this project is that I am to deploy
>> it in
>> the company
>> I work for. I'll be integrating it into our web-framework (doing a
>> new
>> view) and making
>> sure it works with our imap and ldap servers in the way we want.
>> The users will be simple people, not always IT-educated, so
>> user-experience is an
>> important factor. The amount of users we will have is about
>> 100-500 so
>> performance
>> can be a factor as well.
>>
>
> I see. Probably Leonard can give us an idea on how many users are
> using jwma at NCAR/UCAR and what the required infrastructure is.
>
Hi,
I run the development version here at NCAR where there are about 1200
employees. Some groups have their own webmail, many use my solution
(Jwma) because I'm in the central infrastructure provider group. It
runs in Tomcat 5.0.x on a Sun 480. People who complain about
perceived performance are those who have very large inboxes or
haven't set the correct root folder (in which case IMAP is traversing
the entire user home directory).
==Leonard
==Leonard E. Sitongia
Web Engineering Group
National Center for Atmospheric Research
P.O. Box 3000 Boulder CO 80307 USA
sit...@uc... voice: (303)497-2454 fax: (303)497-1804
|
Thanks for helping keep SourceForge clean.
X