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 |