lack luster features
I'm new to zimbra. I've just installed the Zimbra Desktop on CentOS5. It installed fine and initially ran. However, while downloading mail from my POP3 account, the jetty server crapped out several times. I have about 3K messages so it took a while. The first time it crashed, it took a while for me to figure out what was wrong and how to get it to continue. I got a "cannot connect to localhost" on whatever port its on. Then, I had to restart it at least 10 times while my mail was downloading.
* This should not happen in the first place. If it does, it should be rare. This is a bug.
* The documentation was not helpful in figuring out how to resolve this issue. I nearly chucked the Zimbra Desktop due to this.
After finally getting all of my mail. I started using the Zimbra Desktop. There does not seem to be an import/export feature for mail. I could not find it anywhere in the GUI. If i missed it please let me know where it is and how to use it.
* Both importing and exporting mail are extremely important. If the Zimbra Desktop cannot do this, then it is little more than a toy.
* Importing is necessary because users may have already dowloaded and removed mail from a server.
* If importing is not both possible and easy, then Zimbra Desktop has limited itself extremely.
* Exporting is of paramount importance: even more important than importing. A user needs to be able to export mail to a standard format. Although the Derby DB stores the mail in text files in the store dir; it is saved in a non-standard format that cannot be used anywhere but in the Zimbra Desktop. That is absolutely horrible.
* During any kind of upgrade from old versions of Zimbra Desktop to new version, it would be wise to export the mail to a safe location, then re-import it when after the upgrade. There is a note in the installation instructions that says to delete the entire Zimbra dir when upgrading versions prior to some build number and that the mail is safely stored on the server. That is horrible assumption on the part of the developers. User have the ability to delete their mail from the server after retrieving it.
* The lack of an export for mail destroys the concept of freedom. If a user cannot freely and easily migrate their mail from Zimbra Deskop to a standard format for use in another tool, then Zimbra Desktop is a jail. Nothing is perfect, and no tool is perfect. But if a tool makes it hard for a user to leave, then the result will be a bad impression of the tool and the likelihood of that user returning to that tool will be significantly diminished. I, for one, am the type to never return when the cost of leaving is high. I don't like jail and I have no desire to be imprisoned by any tool including Zimbra Desktop.
The configurable options for Zimbra Desktop are lacking in ability.
* in the setup; downloading mail; get new mail option: only a handful of choices are available and there is no option for the user to enter a user set frequency. "every 5 minutes" is the most frequent option. That is simply inadequate.
* in the preferences; displaying messages; display option: only 10, 25, 50, and 100 are available. That make sense for a thin client reaching across the internet to a mail server, but is absolutely absurd for a "thick" client whose mail is served up by the localhost. If I am not mistaken, Zimbra Desktop is supposed to be a thick client. I understand the concept that it a "copy" of the webclient and is simply hitting a local email service; however, if Zimbra Desktop intends to be a true thick client and compete with other thick clients, then it cannot be a simple copy of the webclient: it must be a fork with more features and definitely more configurable options. This is a show stopper for me. If I cannot view all of the messages in a folder, then I cannot use Zimbra Desktop.
* mail filters; there is no option to execute a local script as the action portion of the filter. I don't know how many ordinary users that would find this useful, but I am a developer. I currently use Evolution which has this feature. I use it often. Although I can jump through a few hoops to get a similar behavior by using the "forward to" option, I'd rather keep things simple and just execute the script from my thick client.
* There are absolutely no options for handling received and read mail confirmations. How does the Zimbra Desktop respond to a request for receipt of mail? How does it respond to the request for a request for read mail confirmation? Did I miss something in the documentation? If so, let me know where it is and what the behavior is. But beyond knowing what the behavior is, it needs to be configurable. Having no choice in how the Zimbra Desktop will respond to these requests is horrible. Alone, the lack of this feature would not be enough to make me drop the tool, but it is a strong negative.
Since I am new to Zimbra Desktop, I may have simply "not found" features that do exist. So, I'm asking for a Zimbra Desktop expert to please review my comments and address each item. I need to know if the Zimbra Deskop is a tool that I can use. Please help.
Thanks in advance.
not sure what you ran into, but from your description it's hard for me to guess what went wrong during your initial sync.
exporting will be implemented as backup. data exported that way can be restored. however there's no importing of 3rd party data.
there will be an every 1 minute option in the next release.
display will be limited to options like 10, 25, 50, 100. please keep in mind that zimbra display is very much search oriented. users are encouraged to take advantage of saved searches for productivity. we don't intend to show a scroll bar for users to navigate 100K messages in Inbox.
And I'm not joking about have 100K messages in Inbox. Some of our users have already crossed over that threshold.
local mail filters are coming.
There's no support yet for delivery receipts and read receipts.
Thanks jjzhuang for replying...
I don't know what I ran into either with the initial sync... I didn't get any (that I was aware of) error messages except that it could not connect to the server. Something that I didn't mention before was that even after trying to restart the desktop application... it would continue to complain about not connecting to the server. I had to restart the server manually.... Why not do the following... when starting the desktop, check to see of the server is running... if it is NOT runnig, then start the server before starting the desktop... simple enough.... Also, if the desktop detects that it cannot connect to the server... why not have the desktop spawn a process to start the server??? If you are concerned with ending up in a cycle.. then keep track of the number of occurances within a given timeframe and stop if it exceeds a set limit.
You said that exporting will be implemented as a backup.... that's good... but in what format will it be in? will it be a standard format?
Also you said that there's no importing. Thanks for making that clear. It is hard for me to understand why that is not high on the list of priorities.
that's good about the evry 1 minute option, i'll settle for that... but i'd rather see a user defined option. let the user pick the frequency... you can bound it in a range if you feel it is necessary; say 1 to 20 min...
on the number of messages... i understand why you don't want to display 100K messages.... but there is a big difference between 100 and 100K. I can live with a compromise on this but 100 is just too limitting.. what's wrong with adding 500, 1000, 2000, and 5000 options? maybe even a 10,000? typically i won't need to see that many... mainly becuase i'll divide up my mail into folders... but... during times of transition i need to grab large chunks of mail at a time... the 100 option is way too limitting.
i think for pop accounts zdesktop already supports local mail filters... can you double check that for me... I have an option to create filters in my install of zdeskop... is that not a local version? keep in mind that i'm hitting a non-zimbra pop account as my email server. Specifically, I was aking for a "pipe to program" option as the action part of a filter. That option is NOT currently in the list. However it is an extremely useful option.
Ok so there's no support for delivery and read receipts.... But what does that mean specifically? Does that mean that zdesktop ignores delivery and read receipts: does NOT respond to them whatsoever? Or does that mean that zdesktop does respond to them, but the user has no control over the response. I've see the latter case many times.
Thanks again for you reply...
The new version does indeed auto-start the background server if it's not running.
The backup format is going to be standard targz of mail item objects. Some of these objects will have two related files, one storing metadata and the other a MIME; some other objects will only have metadata.
WRT the issue of limiting to 100. I think it's a user habit thing. It depends on your past experience and personal taste. Maybe there is a case to be make to have the choice of listing more than 100, but what I can tell you is many users actually loathe the vertical scroll bar. Also once you becomes dependent on search based list, this becomes a none issue. For example, my own search string is "in:inbox ((is:unread and is:tofromccme) or is:flagged) sort:dateasc". You can use that as a saved query or even make it your default query. If you receive tons of messages everyday, my personal experience is the scroll bar will not help you much.
Regarding filters, a Zimbra account will run filters on the server side, but a POP/IMAP account will run filters locally.
There's no receipts support. We simple don't send any.
Continuing a bit, as I started to reply got sidetracked on something & JJ responded :p
Re 'when starting the desktop if server not running start it' this is already done in the next public release. See Bug 26983 - prism startup work & Bug 27903 - zdesktop client starts zdesktop services but doesn't open the ui - don't remember the actual one it was implemented in but those two should outline it.
Re number of messages: Anticipating a 'anti-search backlash' as I think you're talking about needing to take action on lots of items at once; to elaborate further, having a limit helps save memory/IO/CPU cycles, & reduces the strain of having to render them all in a browser (against a server it also reduces bandwidth) but of course there are certainly situations where you might not care or 100 doesn't begin to affect performance - thus there is an zimbraPrefMailItemsPerPage attribute which can actually go higher (though it doesn't add it to the user selectable drop down - it just applies it). You can vote for Bug 7411 - allow display of greater than 100 (or arbitrary number) items per page for consideration of easy user-settable higher than 100, though most (and it sounds like you) just really want to vote for Bug 4175 - Permit the selection of all messages in a folder so you can take action on lots of mail items at one time.
Re read receipts - we don't send a reply/ignore them - vote for Bug 7257 - Support read receipts and delivery reports in webmail & Bug 12852 - Track and show status of email which need to be completed before we port that feature to Zimbra Desktop.
Re import/exports I see what you're saying about technically discriminating against small server quotas, ultra-low bandwidth users, and POP. As to import offline content for IMAP you could upload existing items to your server then retrieve them into Zimbra Desktop.
(I honestly haven't checked if you're able import/post to Zimbra Desktop with curl -u username:yourpassword --data-binary @/folder/file.txt http:// server/service/home/username/inbox)
I know this totally doesn't fit your situation, but just pointing out (remember the roots of Zimbra Desktop) if against a ZCS server there are import tools for Domino/Exchange/PST's, plus lots lots of connectors like ZCO, iSync, or the Evolution connector. Imapsync is very common, and there are some perl/python scripts for mbox files. There is an RFE for Bug 27036 - offline : Import mail from other desktop clients but as there's so many different formats coming from other programs it'd probably be a designated list of imports from programs like Thunderbird, Outlook, Evolution, etc - which we haven't nailed down or as JJ said haven't committed to doing anything with as of yet.
As for exporting, again there's always the ability to connect to an IMAP server (plenty of free accounts out there) and even if you don't want to go that route you're not 'jail locked'. The .msg (store folder) or .eml (from a REST UR like http:// localhost:7633/service/home/~/inbox.zip) can be read in some other programs - yes I know that's devoid of metadata like read status, flags, tags, and folder structure (unless you recurse the REST url for structure) heck someone even made a Zimlet to parse messages into .txt files & put all the attachments into a folder. (Though I realize without a rebuild in the current version of Zimbra Desktop it's not an easy user deploy to add Zimlets.) Obviously the previously mentioned upcoming Zimbra Desktop backup -gzipped tar of a metadata & MIME file- might suit you as well.
You can currently grab appointments by visiting /calendar.ics address books by /contacts.csv or see the preferences tab to do so via GUI. Sry to ramble, just trying to point out the typical 'this isn't import/export compliant to my program' wording has flaws - for example, here's the .csv formats we allow easy export to - MS certainly doesn't stick to one format do they?:
So in short, as to the world of exports/imports there's just so many formats - keep in mind it started as a ZCS server sync, then added IMAP & POP, which is the basis for a lot of where Zimbra Desktop currently stands as we bring it into the thick-client arena. You're more than welcome to file an RFE for the format your interested about importing from, or exporting to. :)
Thank you mmorse for taking a stab at answering my questions...
I appreciate the detail that you went into. However, between the responses I got from you and jjzhuang, I'm getting a sense that the culture at Zimbra is the limiting factor. At the end of your reply, you said "MS certainly doesn't stick to one format do they". And you are correct, they don't. However, if Zimbra plans to use or is using Microsoft as its model, then I want nothing to do with Zimbra. I suspect that a fair number of your clients would agree with me on that point.
Using zDesktop thus far has filled me with the feeling of being confined. There are way too many limits. Although some limits are necessary, too many limits destroy the impression of freedom. For example, in response to my suggestion:
"i'd rather see a user defined option. let the user pick the frequency... you can bound it in a range if you feel it is necessary; say 1 to 20 min..."
"we don't want to allow user to pick something like 'check with server every 5 seconds'."
What part of my suggestion included an option for every 5 seconds.... none. But allowing the user to choose his own interval out of a range of 1 to 20 min gives a sense of control and therefore freedom to the user. Locking the user down to a set an arbitray set, say of 1,2,5, and 10 as options offers some control to the user but unnecessarily confines them to only those choices: the sense of freedom is lost. If this were the only place it occurred then it would be no big deal. However, zDesktop seems to embrace that model and it is used over and over. Hence, the sense of freedom is lost all over the place in zDesktop. It's not just the concept of offering a range verses a small subset of the range: its the concept that zDesktop makes unnecessary decisions for the user and thereby forcing the user to live with those choices rather than allowing the user to choose for himself.
Freedom... why I don't think zDeskop has it:
1) the lack of mail import of a standard mail format makes it difficult for me to start using the zDesktop.
2) the lack of mail export makes it difficult for me to leave. If it's hard for me to leave, then why should I invest any time in using the tool?
3) the options available while using the zDesktop are very limiting.
Importing and exporting mail is of extreme importance. The mail belongs to the user, not to Zimbra nor zDesktop. Have you ever used an application.. generated data from it... lots of it... but then support of for the application died: the company get sold or goes out of business or the opensource team developing it gets disbanded or splits up. What happens to the user's data at that point? It really sucks when the data cannot be used by some other similar tool. Well, an email client is an application where there are many similar tools. Vendors for email clients have come and gone and will continue to do so. If I am not mistaken, Microsoft is trying to acquire Yahoo. What do you think will happen to Zimbra if they do that?
I see that you have many options for contact CSV formats... seems nice but are they really unnecessary. Have you considered vCard? and for calendaring: iCalendar or iCal? If you want to offer a host of other choices.. that's OK, but why don't you have the obvious standards. Many if not most of the major players can import the standards.
For the importing and exporting of mail, have you considered the mbox format? How difficult can it be to write a converter from your internal format to/from the mbox format? Adding that alone would address most of your import/export usecases for mail. Then if you throw in the same for Microsoft's pst format, you could render this usecase completely implemented. Although I have little to no need for the pst format I recognize that many people do.
I have been using email for years. I have mail.. lots of it... and much of it is no longer on the server. Since zDesktop has no way for me to import that mail.... I would be forced to use multiple email clients if I wanted to use zDesktop. There are many reasons, valid reasons why mail would not exist on the server but would exist in the thick email client, so ignoring this usecase is a bad decision. The option you gave me to some how get the mail back to the server so that zDesktop can get it was a nice try, but is unacceptable.
As for the number of messages to display, I've discusses the general limiting factor of the current implementation already. The two bugs that you mentioned:
"7411 - allow display of greater than 100 (or arbitrary number) items per page"
"4175 - Permit the selection of all messages in a folder"
are both valid. They both need to be implemented. I can understand your concerns about performance, however other thick email clients don't seem to have any problem displaying thousands of emails. So limiting the user to 100 on a thick client is preposterous.
What's wrong with allowing the user to choose from a large set that includes 500, 1000, 2000, 5000, 10,000, and ALL as options? If a user sees that his performance drops significantly at 5000, then he can choose a lower value. But that will not be true for all users. Another user's machine might function fine displaying 10,000 messages. And during times of transition, when very large numbers of messages need to be acted upon, the ALL option would come in handy. If you want to make it a range rather than a subset and let the user choose the value, that would be fine as well, so long as ALL would still be an option. Maybe 10 to 10K as the range with a radio button to select ALL or the range. It would also be acceptable to only allow the ALL option for the current session: meaning that the zDesktop would default to the range setting every time it starts. The user would have to choose ALL for that session to allow him to do actions in mass.
That's all I have for now...
Thank you for your time.
The point was there's lots of formats, not a company mindset discussion. We work every day to integrate and bring to as many 'industry standards' set by other companies to bare - we could discuss RFC's all day & we participate in the formation of many :p
Originally Posted by zknight
Open an RFE. I did notice what you we're saying, we have lots going on, it's possible JJ just missed your emphasis.
Originally Posted by zknight
Exporting we've already talked about, could there be more options? Of course. There's .msg & .eml with Metadata/MIME via the backup option coming soon. I'll address import in your later section below.
Originally Posted by zknight
We're members of CalConnect so I don't think you're gonna have a problem with Zimbra not adhering to standards on the calendaring front.
Originally Posted by zknight
As already stated, you can export/import a.ics from the preferences > calendar tab easily with a nice GUI, it's also available via REST:
http:// localhost:7633/service/home/~/calendar.ics or free-busy data via .ifb (change the url on the end if in another calendar or addressbook) here's the GUI:
Originally Posted by mmorse
vCard is also possible: Until RFE 20742 - export vcard vcf of contact from web client is finished an alternative is to move it to its own address book, then in another browser window to go: server.domain.com/home/~/addressbook.vcf
Or if you want to download a bunch: server.domain.com/home/~/addressbook.zip
You can construct the url in a variety of ways ie:
-'user' & 'home', as well as 'service' & 'zimbra' are mostly interchangeable/often not needed
-You can also replace accountnames with ~ for simplicity.
Importing them is another RFE (can't find it right now) but for example here's one on importing them when they come in as new mail Bug 14491 - view attached vCard in Zimbra Web UI (with righ-click options for import into AB) Server side I use: curl -u user:mypassword --data-binary @/tmp/newcontact.vcf http:// server/service/home/user/contacts?fmt=vcf
The server side perl/pyton previously mentioned is here: Migrating_from_MBOX_files : User Migration - Zimbra :: Wiki To make that into a wizard Bug 13926 - mbox and maildir migration tool Yes they're server side tools right now - let me explain these references after the next paragraph.
Originally Posted by zknight
Not ignoring those coming from the POP / not server side stored / non-IMAP or non-ZCW world. With some things we're taking a build into web-client approach (these things will obviously work better in ZDesktop), for others we're using standalone wizards - the point I was trying to make earlier is that while at present most of those aren't possible to run against Zimbra Desktop, we're still defining that road.
Originally Posted by zknight
Dude, that's exactly why there are those two RFEs - put your show of support for them there in the form of a vote or comments.
Originally Posted by zknight
Just to orient you a bit:
The blog has lots of good articles - you might checkout: Open Source Product Management: How do features get into Zimbra?
Bugs & RFE's (requests for enhancements) can be filed/voted for in Bugzilla & tracked (see priorities & what release their going into) via PMweb.
Last but definitely not least - the Wiki has all sorts of collective knowledge in it.
Not trying to fight ya back, seriously keep bringing feedback like this up. If it simply turns out that in its current state ZDesktop is not for you I understand, it's how the cookie crumbles, and I hope you try it out in the future. Zimbra is about something more - giving back, enhancing, and shaping the future of mail. Your ideas are what keep us up at 2AM pushing the limits of collaboration. :cool:
Thanks again mmorse for your detailed response...
The current state of zDesktop is what is it is... I understand you are trying to build a thick client out of a thin one and that improvements are on the way... That's good.. and I don't mind helping out by providing feedback, creating RFE's and voting on Bugs... However, it may not be the right time for me to jump in. Based on all of the replies, the current state of the zDesktop is lacking some features that I absolutely need.
Something to keep in mind for me... I am using zDesktop as a pure thick client. I do not have a zimbra server for my mail. I tested it using one of my POP mail accounts. So any suggestions that you have given me that reference the web client are absolutely useless to me. I need zDesktop to function well as a server agnostic, thick email client.
Some of my motivations are personal... meaning they are based on what I would like to see in a thick email client. While other's are corporate. I will be standing up a Zimbra email server to host my companies mail. The features of the web client are acceptable as a web client. However I have users that live in the MS world as well as those in the Linux world. It would have been nice if the zDesktop was mature enough for me to recommend to all of my users. However, my assessment is that zDesktop is not ready. My MS users would shoot me if the were not allowed to use Outlook and were forced to use zDesktop. My users on both sides of the fence have both corporate and non-corporate mail and they use a single, thick client to access that mail. Some use Outlook while others use Evolution or Thunderbird. All of which allow them to access their corporate and non-corporate mail with robust features. Based on what I've seen and what you have told me, I cannot recommend zDesktop as an alternative to my users.
Totally understand - our goal is to make it a first choice for a standalone client as well - thanks for the thoughtful and well articulated criticism.
Hope you enjoy ZCS when you get it up and running (& if you choose to purchase NE combining that with ZCO).