[mmorse]

Originally Posted by zknight

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.

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

Originally Posted by zknight

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..."

jjzhuang said:
"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.

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

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?

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

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.

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.
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:

Originally Posted by mmorse

You can currently grab appointments by visiting /calendar.ics address books by /contacts.csv or see the preferences tab to do so via GUI.

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:



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/accountname
/zimbra/user/~/
/zimbra/home/~/
/zimbra/user/accountnamehere/
/zimbra/home/accountnameehere/
/service/home/~

-'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

Originally Posted by zknight

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.

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

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.

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

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.

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.

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.