jwma-devel — Jwma Development Mailing List

[Jwma-devel] Pagination feature in jwma

[Yogeen H. <yo...@is...>]

Hello all,

We would like to know if there is any plan to implement pagination feature
in jwma mail client.

If there is no such plan then please give us some hints so that we can
customize on our own.

regards
-yogeen honnavar
-- 
Yogeen Honnavar

------------------------------------------------------------------------------
Confidentiality Notice: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
------------------------------------------------------------------------------

[Jwma-devel] Off-topic: Translators wanted for opensource

[Samuel M. (Groenkloof) <sa...@tr...>]

G'day everyone

I noticed that this project is quite active on Source Forge, and for 
that reason I'd like to tell you about our translation project.  I'm 
also hoping that some of you might be able to help us with translations 
or ideas.

The project is called Decathlon because we want to encourage people who 
feel passionate about their language to translate up to ten or more 
opensource programs into their languages in 2008.  This year, we limit 
our selection of translated programs to applications aimed at end-users, 
and preferably programs that run on multiple platforms.

All translations are done in our web-based translations system, Pootle. 
  The value of Pootle is that a team of translators can work together on 
a single file.  Pootle also has quality checking features, to ensure 
that translations don't break the software they are used in.   Pootle 
requires the Gettext PO format, but we can convert certain other formats 
to and from PO.

More information about the Decathlon project can be found here:
http://translate.sourceforge.net/wiki/decathlon/mainpage

Our Pootle server is here:
http://pootle.locamotion.org/

I look forward to hearing from anyone who is interested.  You are 
welcome to pass this e-mail on to anyone you think may be interested.

Sincerely

Samuel Murray
Decathlon project leader

[Jwma-devel] OT: Invitation to participate in research project

[Ben A. <ben...@st...>]

Hello there

I would greatly appreciate a small amount of your time to assist with
my doctoral research at The University of Newcastle. The research
concerns open source licensing and we're seeking developers working on
Java projects. The research is supervised, ethics-approved, anonymous
and results will be freely available. Participation will also provide a
custom licensing report for your project. To learn more, please visit:

   http://licensing-research.newcastle.edu.au

Thanks for reading this email, and I hope you'll consider participating.

Best regards
Ben Alex

(My apologies for being off-topic; this list will not be emailed again)

[Jwma-devel] search messages

[=?iso-8859-1?q?<mir...@wa...>]

<br /><table cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" border=3D=
"0"><tbody><tr><td>Hello everybody,<br />After posting in Help and Feat=
ures forums, and some other problems with <br />jwma-list, I join to th=
is list to follow the postings...<br />As I said, I developed a first d=
raft for searching messages (get <br />messages matching a pattern). I =
don't have strong knowledge of <br />java/servlets/jsp, so I'm sure my =
code can be widely improved.<br />The fact is more or less I get search=
ing messages basing on <br />From/Subject/Body fields, but I'm not sure=
 the way of searching. I <br />mean, if I specified 2 or more fields, h=
ow should the search work? With <br />OR or with AND between the fields=
? For example, when you search a <br />message like this: <br />- From:=
 john <br />- Subject: holidays <br />- Body: empty (nothing written) <=
br />In this case, should you see only those messages with From field=3D=
 John <br />AND Subject field=3D holidays?=A0 <br />Or should you see t=
hose messages with From field=3D John and Subject <br />field=3D whatev=
er OR From field=3D whatever and Subject field=3D holidays OR <br />Fro=
m field=3D John and Subject field=3D holidays? <br /><br />To introduce=
 to the search engine, I use javax. mail.search package and <br />it pr=
ovides all mechanisms to do the search including the possibility <br />=
of doing logical operators between the fields...<br /><br />Another thi=
ngs is that I use Search mechanism inside the folder one is <br />in be=
cause at least for beginning this is easier, but as Leonard told <br />=
me this needs to be discussed...<br /><br />Of course, I share the code=
, but I'm sure that it doesn't measure up <br />to the rest of jwma pro=
ject....<br /><br />Thanks<br />Rgds,<br />Miriam<br /></td></tr></tbod=
y></table><br/><br/><a href=3D"http://webmail.wanadoo.es">webmail.wanad=
oo.es </a>- Tu correo gratuito, r=E1pido y en espa=F1ol

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Dieter W. <dwi...@gm...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Pavel D. <pav...@gm...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Leonard S. <sit...@uc...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Leonard S. <sit...@uc...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Leonard S. <sit...@uc...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Dieter W. <dwi...@gm...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Pavel D. <pav...@gm...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Dieter W. <dwi...@gm...>]

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

Re: [Jwma-devel] LDAP-plugin...

[Pavel D. <pav...@gm...>]

By the way, the code now uses JNDI instead of jldap.
It was really easy to change and jndi seems to have better features as well=
.
I'll be working on refactoring it a little to improve the code-base and see=
 if
I can get a grip on how the xml-settings work so I don't have to
hardcode stuff =3D)


On 20/05/05, Pavel Denisov <pav...@gm...> wrote:
> > Great, thanks, Pavel.
> >
> > Is your work on the 0.9.8 release, or using the CVS code base?
>=20
> CVS-struts version.
>=20
> --
>=20
> // Pavel
>=20


--=20

// Pavel

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Pavel D. <pav...@gm...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Dieter W. <dwi...@gm...>]

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

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Pavel D. <pav...@gm...>]

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

Re: [Jwma-devel] A bug? Imap-folders...

[Dieter W. <dwi...@gm...>]

Pavel,

> Do you mean that jwma at the moment doesn't support folders apart from
> the default folder (i.e. inbox)?
No. jwma does support as many folders as you wish to have. Just be sure 
that you know what type of store you have got and that it is configured 
correctly (mixed or plain).

> What I am experiencing is that when I login to my mail through jwma, I don't
> see any folders but the Inbox folder.

There are two possibilities:
1. You haven't configured jwma correctly
2. The folders are not subscribed



I would prefer if we could keep development and usage questions apart.I 
kindly ask you to post questions that refer to development to this list 
(jwma-devel).

All questions about usage are welcome on:
The Help Fora, the jwm...@li... as well as the 
Support Tracker.

This would help us a lot to keep things organized and manage communication.

Thanks in advance.

Best Regards,
Dieter

Re: [Jwma-devel] A bug? Imap-folders...

[Pavel D. <pav...@gm...>]

Hi, Dieter!

On 20/05/05, Dieter Wimberger <dwi...@gm...> wrote:
> Pavel,
>=20
> > I have several folders in imap-store. I can see light-folders created
> > for each and one of them in the log, but I can't see them anywhere on
> > the interface. Or am I missing something obvious?

> It's probably the folder list cache that you are looking at?
> It should happen only when you are entering a new folder (and one light
> folder is created for each subfolder in that folder).

Do you mean that jwma at the moment doesn't support folders apart from
the default folder (i.e. inbox)?
What I am experiencing is that when I login to my mail through jwma, I don'=
t
see any folders but the Inbox folder.

Regards,

--=20

// Pavel

Re: [Jwma-devel] A bug? Imap-folders...

[Dieter W. <dwi...@gm...>]

Pavel,

> I have several folders in imap-store. I can see light-folders created
> for each and one of them in the log, but I can't see them anywhere on
> the interface. Or am I missing something obvious?
It's probably the folder list cache that you are looking at?
It should happen only when you are entering a new folder (and one light 
folder is created for each subfolder in that folder).

Regards,
Dieter

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Dieter W. <dwi...@gm...>]

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

[Jwma-devel] A bug? Imap-folders...

[Pavel D. <pav...@gm...>]

I have several folders in imap-store. I can see light-folders created
for each and one of them in the log, but I can't see them anywhere on
the interface. Or am I missing something obvious?

Cheers!

--=20

// Pavel

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Pavel D. <pav...@gm...>]

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

Re: [Jwma-devel] LDAP-plugin...

[Pavel D. <pav...@gm...>]

> Great, thanks, Pavel.
>=20
> Is your work on the 0.9.8 release, or using the CVS code base?

CVS-struts version.


--=20

// Pavel

Re: [Jwma-devel] contacts_model_contactgroup Exception...

[Dieter W. <dwi...@gm...>]

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, 

Re: [Jwma-devel] LDAP-plugin...

[Leonard S. <sit...@uc...>]

On May 19, 2005, at 1:06 AM, Pavel Denisov wrote:

> I'm just moving this conversation from the message-boards to the  
> developer-list.
>


Great, thanks, Pavel.

Is your work on the 0.9.8 release, or using the CVS code base?

==Leonard