Slashdot Mirror
Aethera Beta 1 Released
StupiDiot writes: "Aethra is a open source mail client which follows in the steps of LookOut, and is being developed by the Kompany. In case you haven't been
following, Aethera is theKompany's fork of the greatly hyped/anticipated Magellan project. Beta 1 of Aethera sports POP3, SMTP, HTML, DnD, a contacts interface, sticky notes, and more. IMAP, Calendar support, etc., are promised for the next beta. There is no mention of the license although source is available from the Web site -- most of the source files seem to be under the BSD license.
" So, I downloaded it and tried playing with is last night - it's a very cool, very slick program - the competition between this and the Gnome-equivalent Evolution will be interesting, as always. Regardless of which wins, the race to produce an Outlook-killer is on.
Elm, Pine, mutt, kmail, or one of several other mailers all work fine for my mail. I don't need anouther mail client. I do however need a way to do calendaring, and it needs to be compatable with everyone else's calendar. I don't care what your mail tool is, I'm used to pine and we can communicate.
This week we are in the process of switchig from Synchronize (with unix or windows clients) to exchange (and citrix for those with unix on their desk top - most of us) because the main office is exchange and those who regularly go to headquarts have a secratary just to keep the two systems in sync. It will work, but from playing with citrix I've already realized it is slow.
Problem is anyone can write a mail client. ASCII is an old standard. All the protocols are well described in rfcs. There are plenty of resources on network programing for just about any OS. Exchange is not well documented however. Good luck creating your own client - it is unlikely to work.
As soon as you talk HTML, you must think portability across platforms and applications, because HTML is supposed to be a platform-independant solution. (on the other hand, plain text *is* a solution, hands down). But 90% of the problem with HTML messages that are sent are the same 90% of the problem with the rest of the web -- these people have no idea how to write HTML code properly. From using malformed HTML markup to using IE-only tricks, these messages are barely readable on most browsers -- strip away the HTML to leave text, and you usually have something unreadable due to poor formating or hiding the content in the HTML (even though, theorhetically, removing HTML tags from a proper HTML document should leave a easily readible plain text file). This is a big concern to anyone using wireless internet devices, such as cel phones -- if that HTML message parsed down to text only is unreadible at 80x24, imaging trying to read it at 25x4, or worse.
You then have to conside the other problem, and that is compatibility with HTML browsers. Most of these email clients link to an existing browser engine, and embed it into a window. Lookout, obvious, and IIRC, Evolution will grab the Gecko engine from mozilla to do any HTML display. So you first run into the standard problems with HTML rendering in the various engines. But particularly on the windows side, these instances of the browser are NOT sandboxes -- all the standard hacks and the like will work in terms of, say, malicious buffer overruns from URLs. In addition, the 1x1 web bugs and other tricks can easily be inserted into the HTML email, and since you usually can't set different privacy and security for that browser instance, you're as vunerable as you would be with normal browsing. Plus I can send code in HTML that would normally be picked up by a cookie-blocker or such if the user had viewed the page via a normal HTTP connection, but would not be blocked in this case, and do the usual tricks of reporting back to a server.
Add to all of this that there is no clear cut standard for sending HTML email to begin with. Sometimes I'll get it in the plaintext client as HTML right after the headers, sometimes as two parts of a mime-encoded message, sometimes as an attachment -- it's a mess!
I believe that two things need to be done to make HTML email a practical thing that sits on top of the current email system that we have. Obviously, we need a standard for how to send and recieve email. Modifying the RFC for email servers to be able to recognize when an email client is sending in HTML, so that it can tag the message appropriately, and then when mail is being retrieved, a numeric can be sent prior to retrival to indicate that HTML or plaintext is desired (ala BINARY and ASCII of ftp servers). The server then would strip any HTML out of messages that contain it before sending the message out, if the plain text feature was enabled.
The other thing, more serious, is to develop a subset of HTML that can be used for email, similar to how /. does a trim of html -encoded messages. Restrict the set to only layout messages, such as B, H1, as well as links etc, and avoid anything that moves outside of just display, such as IMG, SCRIPT, EMBED, etc, such that what really can be sent is a what RTF can provide, in HTML terms. Mail clients can parse this before sending, but the job again would be up to the mail servers.
Putting such a new email server in place, as long as the way HTML was sent uses one of the current methods in use today, would not disrupt how older servers would continue to function, since only the input and output servers have any extra processing of messages to do. But there's a long way to go before this could be commonplace everywhere... it would require much help from MS and other vendors, and they're probably not going to cave in from this.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
This may be one division between anyone introduced to the Internet pre-Netscape, and those after that point (give or take a year). I have no problem with the defacto standards of viewing plaintext "markup" like *emphasized words* or SHOUTING, since I've been reading email and usenet for at least 10 years now. And on the other hand, I find that outside of bold and italics, any color coding done in passages is distracting. The above poster obviously feels different. And while I would love my way to be the right way, I do realize that 90% of the people using the net today are going to be of the latter state of mind. C'est la vie, but here's the important point:
We're moving 'backwards' in terms of display technologies as we get more wireless internet devices where you only have a 24x4 character display to show a message. If only text email existed, there would not be a single problem with handling mail on these devices, but with HTML email abuses, they have to figure out how to parse everything to fit on that. Sure, maybe in 2 years we'll have holograph, 3d displays on all these things capable of effectively large graphic displays, but the NOW is that we don't. If you design for the most effective lowest common demonator, no one will complain. ("Most effective" to avoid any slippery slopes -- I *expect* that to play Q3A, I'm going to need a powerful system, but to read email, I should be able to do that on a Vic20.).
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Now way,
While there products are meant to mimic some of the functionality of some MS products, the look and behaviour vary a lot.
Apple may have successfully sued people for copying it's UI, but you can't sue someone simply for making an IDE (which, I seem to recall, wasn't even started by them..) or for making a flowchart program.
What you can do is sue someone for blatently copying a UI (like, oh say Evolution-Outlook or Gnumeric-Excel...)
It would be funny to see MS trying to sue someone for making a copeting product..
Cheers
WOW
/var/mail/tackhead no doubt.
I mean, I read all these books about people who scream and holler and stamp their feet with respect to change, but I never believed I would actually see the like.
Psst. While you weren't looking, your terminal changed to use ISO-latin. That's eight bits. It might even use unicode of all things, not only 8 bits but with funky escapes to encode 16 bit chars. Neither of which will show up on your IBM Codepage console on the 386sx running Linux 0.9 for which you read mail using cat
And despite your protestations, most mail readers got MIME support. Perhaps you've heard of it: it's what that "web" thing uses too.
And despite your ranting and raving, even a great many technically clueful people really don't give a damn about what you consider acceptable documents to transfer over e-mail.
Cope.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Funny how you complain about HTML mail, specifically of people using it to put things in boldface, then later on down, put "by default" in boldface...
Would you rather it were RTF? I like being able to mark up my email, thanks very much.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
> The current batch of clients that support HTML email (include Lookout) do NOT have any such feature
Outlook most certainly can, including Outlook Express. Simply open the contact in the address book and check "Send E-Mail using plain text only". Besides, I don't share your feelings about HTML email. Each new medium developed should be able to repesent information to the richest extent possible. Using plain text only is an artificial limitation that makes only some people happy. Those people should strive to develop email clients that let them strip the plain text out of rich email, but they shouldn't be allowed to dictate what everyone else uses.
All said, there is no denying that a rich medium invites poor taste. Crass use of fonts, colors and sizes can indeed make email very unreadable, but that reflects more on the poor taste and inexperience of the author than on the flaws of the medium. A good email client would offer a sensible set of filters that can let you normalize rich email to whatever you want: full formatting, colors only, fonts only, or plain text only.
You mean something like Pango?
The important bit is the server platform. It is very hard to make cretinous Minesweeper Consulatants and Solitaire Experts that dwell around the coridors of large corps and claim to be from the "Incompetent in Technology" department to use anything but MS Exchange. So anything that can deal with their abominative productions is more than welcome.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Noooooooo!
(this would have been funnier with the multiple o's, but filter stopped me. Damn.
Pope
Freedom is Slavery! Ignorance is Strength! Monopolies offer Choice!
It doesn't mean much now, it's built for the future.
Well, according to a note that I *would* quote (but for the fact that the kde news server just got slashdotted), the president of theKompany says that there is no reason that Aethra can't easily be ported to windows.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Email is a method for communicating. C-o-m-m-u-n-i-c-a-t-i-o-n is the keyword, the issue isnt HTML vs ASCII - it's which method that allows me to communicate more efficently.
<rant>
And beliving that email should stay 7-bited is so narrowminded that it's scary - makes me wonder if you've ever seen the outside the US? (Assuming you're an american, because most others nations have a realistic worldview) . Repeat, Lather, Rinse: The US isn't the entire world. English isnt the only language. 99% OF ALL LANGUAGES CAN'T BE EXPRESSED IN 7-bit ASCII.
So why the fuck are you ranting about the superiority of 7bit ascii? There isnt a single advantage to using 7-bit ascii over MIME or (preferbly) Unicode.
</rant>
-henrik
It may be an OL killer, but *why* all the recent OL killers look almost *exactly* their target looks?! OSS produces better quality, more solid apps, but seems to be enherintly incapable of producing innovative UI.
This may well be explainable: it is not cheap to conduct various usability studies, yet it is still sad nonetheless.
--AP
I know I'm being redundant, this isn't his first reply...
To make the open source movement something the PHBs can understand you have to give them MS-like solutions. An Outlook Killer is a step in this direction. "Sir, why buy 2000 Outlooks (or whatevers) if there's this one for free that we can tailor to due as you, the almight Lord Boss, please?".
Face it, they need a comparison - you can't expect a non-techie to understand that Linux is superior to Windows ?? due to it's stability, you need to make them understand through ca$h ($$$$$$) or something else.
I say, GREAT job guys - keep it up!
--
All browsers' default homepage should read: Don't Panic...
All browsers' default homepage should read: Don't Panic...
Check out the roadmap. Groupware is coming, with shared calendar targeted for March.
Also, if you read through the thread on news.kde.org you'll see that TheKompany will not be open sourcing the groupware server. This is is the way they intend to make money.
(note to /. editors: check the spelling next time...).
ROFL!
Ahum. Sorry, couldn't help myself...
Thimo
--
Avoid the Gates of Hell. Use Linux!
Nono, it's on the same platform. You just have to install a small required library called "linux" to get it to work correctly. You just have to be patient with the install.
So that at least one of the 13 previous people who were also "top-replying" would be encouraged to get some clue and trim out the irrelevant crud ;-)
Why the heck did you, a proponent of "top-posting" - when you posted your reply to Slashdot, which does not (last time I looked) automatically quote text to which you're replying - put your reply at the bottom of your reply to the original poster?
Answer: The same reason peoples' replies belong below the quoted text in email, namely "Here's what Foo said. Here's what Bar said in response. And here's why I agree with Foo and not Bar.", or more bluntly, because people in western cultures read left-to-right and top-to-bottom.
I'm one of those who believes HTML in email is an abomination.
The answer to why I use HTML markup on Slashdot is because Slashdot is accessed through the web. HTML is what web pages are made of; it's therefore appropriate to use HTML.
Email is not the Web. Email is a method for sending text (7-bit text, none of this 8-bit M$ASCII crap even!) between users on two systems.
Since even web browser authors can't render the same pice of HTML identically, and there are only two mainstream browsers, how on earth do you propose to make every email client (from mutt to Elm to Pine to Eudora to Outbreak to Nutscrape to...) render HTML correctly?
Email is not the web. If you want to mark up your email, *emphasize* things or _underline_ them or SCREAM, but do it in 7-bit ASCII, and do it in text.
- Paul Tomblin in alt.sysadmin.recovery, regarding HTML in USENET.I happen to agree with the sentiment when it comes to HTML in email too.
Umm... because 7-bit ASCII is what's in the RFC that specifies what SMTP is?
Because MIME-encoded binaries are 7-bit ASCII, just encoded in base64?
In English, I'd still rather see a "'" or """ instead of the =[hexdigit] that MIME uses -- but I'd rather see =[hexdigit] than the 8-bit "thing" that M$ includes.
Just like I'd much rather see a 7-bit ASCII representation of a base64-encoded JPG than have a mailer just "cat natalieportman.jpg | /bin/mail poorbastard@127.0.0.1"
Non-US character sets will likely wind up in some sort of representation that comes down to 7-bit ASCII too. SMTP is an 8-bit-unclean protocol - and if you use SMTP, you have to figure out how to decode quoted-printable or base64 data.
If you're going UTF-8 (or UTF-16), and the transport is not 8-bit-clean (i.e. if you use SMTP), then you need to do it in 7 bits and do MIME support. RFC2376, IIRC.
Email is about communication across platforms. To the extent possible, it should be independent of the mail client of the sender and the reader.
That's what the RFCs are for.
(Disclaimer: If you're doing groupware - strictly for stuff in the LAN and you control all the clients and all the recipients - you can design an 8-bit-clean transport protocol, and you can blithely send all the 8-bit data you want. Just don't assume that anyone outside your LAN will be able to read it. That is where Lotus Bloats and MSexchange both went wrong, and that's the thing I'd like to see an open-source Outlook-killer not do.)
(Of course, I do agree that that the issue of 8-bit-unclean transport is a wholly separate issue from my stance on HTML mail, since you can do HTML mail in 7-bit, but I'll still bounce it in procmail. It's just that I'll bounce it for a different reason ;-)
Why in the heck would I want my text below the part I'm replying to? So the person can read through 14 consecutive replies before they get to the good stuff?
Because as good Netiquette you should be trimming the text of the message you're quoting to the bare essentials - obviously.
Steve
---
Being that IMAP is a superior protocol , it suprises me that it isn't a high priority. I would try it out, but since there's no IMAP, I'll have to stick with Evolution... Which, has had IMAP from the start, even if it was pretty bad in the first betas...
But I DO have to admit, Aethra DOES look pretty...
-Brandon
...because you can't kill outlook as long as the exchange protocol is closed.
our server is run by microserfs...meaning forwarding is disabled, IMAP and POP are closed.
NO non-microsoft mail client will ever work with our exchange server.
IMHO, exchange and outlook are a better example of Microsoft's antitrust behavior than the browser wars.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
....but Maggellan will be open sourcing theirs..
--
-Oh Granny your eyes are BIG and RED!
-it's from rebooting WinNT servers all night, said the wolf
Why in the heck would I want my text below the part I'm replying to? So the person can read through 14 consecutive replies before they get to the good stuff?
Every email client I've used, I've always changed it so my new text appears on top. Even my Linux ones.
-
-Be a man. Insult me without using an AC.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
When is everyone going to realize that Outlook is not just a mail client? The groupware features of Outlook (on an Exchange backend) are what make Outlook an interesting offer. DHTML/POP3/SMTP/Address books are all great and fine, but that's just a basic need for a simple mail client (they've been built into Outlook Express, Eudora, etc. for a while). Providing these features doesn't approach groupware, it approaches the minimum requirements that people *expect* from a mail program.
What *really* needs to happen is for someone to take the initiative on providing an extensible messaging environment that enables you to offer directory services, calendaring, addressing, forms, event handling, messaging, and VOIP across a corporate environment. SMTP and POP3 just aren't going to meet this need. Those types of features are what separate a mail program from a groupware environment.
Instead, what I really think people are looking for is not so much an Outlook killer (after all, it is in fact only a client) but an Exchange killer. And that needs to be cross platform or else you'll only have minor adoption rates - supporting Linux just won't do (even for the server). I find it hard to get impressed with another "me-too" mail program wanting to be groupware.
I'll grant you the inbox, but hth do you propose a developer to make a compose dialog box without using that interface??
Pine uses a suspiciously similar interface too (It has To:, CC:, Subject: and the message body!) It must be copying Outlook as well!!
---
Video meliora proboque deteriora sequor - Ovidius
look at this link:http://dot.kde.org/979768484/
a lot of talk about licensing issues and a apparent feud between the kompany and magellan developers
Must sys that it still looks nice tho
"Mommy, mommy! The garbage man is here!" "Well, tell him we don't want any!" -- Groucho Marx
on such a project9 79781930/979783107/979801945/
again dot.kde.org http://dot.kde.org/979768484/979777064/979778240/
"Mommy, mommy! The garbage man is here!" "Well, tell him we don't want any!" -- Groucho Marx
Aethra is cool but check out my sig for a small lightweight email client that was built for IMAP. The mistake of a lot of email clients is that they first support POP and then add on IMAP later. It screws up the program since you have to deal with messages differently. Better to start at IMAP (which I consider the "wave of the future" for email anyways) and then "disable" the features for POP. This is not meant to be flaimbait, just a fact of many email clients. Our development on Althea has focused on getting the IMAP right and adding all the Outlookesque features until its fully functional. POP is so far down the road, even LDAP is before it.
Check out Althea for a stable IMAP email client for X. Now with SSL!
yet again the desktop Vs desktop stupidity get's in the way of common sense.
there was the camel mail backend that they could have used, and implemented a kde interface - so why ignore it and the chance of *easier* interoperability between this and evolution??
i know this is still an important project, but people can't ignore existing technologies because of the fact that it was a competitors design.
sad...
i wish i was but oh well
Aethra sounds like Urethra ;)
--
Kiro
DnD? As in "Dungeons and Dragons"? Gee, I hope that the Wizards know.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
elm is solid and lightweight. mutt is solid and featureful. Quit whinin'.
Does my bum look big in this?
Both formats have problems. While I love the direct response system of the unix style, it doesn't fit so well in this age of variable size windows for reading e-mail. It doesn't word-wrap.
Actually, it does. More advanced email clients work out what the indent characters are for each particular segment of text. Bingo! They now know each paragraph for individual word-wrapping, _and_ they know what to indent that paragraph with. Doesn't work very well on single-line replies, though.
Does my bum look big in this?
I bet the developers are pretty pissed with that.
%^#$%! Stupid fingers! *ahem*
>Regardless of which wins, the race to produce an Outlook-killer is on.
Making Outlook killers is easy! Oh, wait, you mean competing applications, not a virus...
Is it fully skinable yet? More importantly, does it have the ability to play MP3's?
No? What! I thought all OpenSource projects these days had to be able to do these two before you can even consider a first release! What were these guys thinking!
We all know that Windows sucks. So why, oh why, do countless Open Source projects spring up that try to slavishly duplicate the look and feel of yet another crap Windows product while leaving out the only good parts of the functionality? And then they call it a "Windows:foo killer". Do they really think Microsoft are the sole arbiters of what constitutes good GUI design?
I don't like the look and feel of Outhouse. And as an email client it sucks big hairy ones. I do like the calendaring, or at least I would if I needed to schedule things with more than one person. So why is this "Outhouse killer" duplicating the look and feel of Outhouse, but not offering any way to do calendaring through a SexChange server?
No thanks. I'll stick to mutt, and occasionally when somebody sends me a Microsoft attachment that I can't read by piping it to strings, I'll fire up Mozilla's email client on my NT machine. It's not great, but at least it knows enough to open up my IMAP inbox by default, unlike Outhouse.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
My company uses Exchange and we all hate it. But everybody loves Outlook. Hell, I like Outlook, but use it in Internet mode, not Exchange native mode, because I can't use IMAP when Outlook is set to use Exchange, though I can set up additional POP3 accounts.
But the server side, Exchange, is a giant piece of bloatware that couldn't stay up for a week if Bill Gate's life depended on it.
You want to hurt Microsoft bad? Come up with a free-as-in-speech, open source, server-side replacement for Exchange, supporting all the features the client, Outlook, wants to use. I haven't got the programming skills to attack this, but I do believe that the route to the desktop is through the server, at least for open source systems.
I think there's a lot to be said for the embrace and extend strategy, and open source should embrace and extend the server side of Microsoft protocols, to get to the client side. As far as I know, reverse engineering to achieve compatibility is still legal in some parts of the world... Is anybody working on this already, and I just never heard about it?
Edith Keeler Must Die
http://www.horde.org/projects.php
:)
I've been using IMP, the webmail portion of HORDE, for quite some time now (no, not me personally; I use mutt. My _users_ have been using it). It's a very nice webmail client, especially with a few patches (for things like importing Outlook address books), and looks similar to Yahoo! mail (apparently; I've not used Yahoo! mail).
Though IMP is the most mature component, they also have Kronolith, which does calendaring. You have to get the code from CVS at the moment, but it is apparently in use in the Real World. Yes, it's a bit simple at the moment, but it's under development, so it _is_ happening.
Note that HORDE is entirely done with PHP, so it _does_ work on MS platforms (the server part, obviously; the client part is a web browser
The best part about providing users with webmail is that there is NO configuration. This is especially good when you are in Baltimore, and a good chunk of your users are in Chicago. You tell them on the phone, "Here is your username/password and the URL, go log in."
Sotto la panca, la capra crepa
WMBC freeform/independent online radio.
> No? What! I thought all OpenSource projects these days had to be able to do these two before you can even consider a first release! What were these guys thinking!
The Law of Software Envelopment: ``Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.''
(Jamie Zawinski)
They clearly got it backward...
Cheers,
--fred
1 reply beneath your current threshold.
Psychos do not explode when the sunlight hits them, I don't care how fucked up they are.
Now, I completely understand that in intraoffice communications, because of the braindead-ness of PHBes, HTML or formatted email proliforates badly, just because they can bold the words "and I want it done NOW!". So it's completely understandable that an email client that is to be used on the rogue linux back in a WinNT environment is going to need to not only understand Lookout's protocols but also the ability to view HTML email directly. In addition, it would help to make conversions from WinNT to Linux systems if such were to occur more easier for the PHBs since they still have their pretty email system.
But please oh please limit it to just that. It should not be too hard to set up, by default, limiting HTML email to certain address sets, specifically ones with the same domain as yours, as well as making sure that HTML email is disabled on a normal install. The address sets that can accept HTML should be able to be customized, of course, in case you have contacts that you normally use HTML email with. I don't care if your office mates all email each other in HTML, but if you have to mail me or anyone else on the outside world that you don't know yet, make sure it's in plain text. The current batch of clients that support HTML email (include Lookout) do NOT have any such feature, and this would be highly recommended for any further email clients.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Please note, before jumping into development of such a server, that the IETF is working on standards for calendaring and scheduling, and several RFCs have already been published. For more info see the ietf-calendar home page.
Unfortunately, I personally know of no open server-side implementation of these standards, though there probably are some. If you know of any, please post here.
Whatever -- e-mail GUI programs tend to look alike, and that's not really a bad thing. At least people recognize what's going on immediately and don't have to familiarize themselves with it too much -- especially when you're trying to replace/compete with Outlook (*including* the database and back office functions), it doesn't hurt to be a little familiar.
Lastly, nobody's stopping you from contributing to Aethera's further development. If you wanna help out, please do so. :-)
cya
Ethelred
Everyone wants to be Ethelred. Even I want to be Ethelred.
But the server side, Exchange, is a giant piece of bloatware that couldn't stay up for a week if Bill Gate's life depended on it.
As someone who has worked professionally with Exchange for some time, I'd have to contradict part of this at least. Sure Exchange is bloated (I've just been dowloading SP4, which is obscenely large ~ 134 MB). I'd have to disagree with the stability accusation, though. I've been doing second line support for about 40 Exchange servers on a corporate network (all running on ridiculously overspecced Compaq servers) and it's proved to be rock solid. The only faults I've had in the last year related to the Lotus Notes connector - a bit of software that makes Charlie Manson look stable - and the occassional hardware glitch.
Using up-to-date service packs, neither NT nor Exchange are anywhere near as flaky as they used to be. As a passionate Linux user, I'm irritated every time I see anti-Linux FUD. However, as a regular NT admin, I'm also irritated by anti-MS FUD There are plenty of real points upon which NT & Exchange can be attacked (price, security, being closed-source) but echoing outdated rhetoric serves no one.
Sorry for the rant. I think I'll go and have another cup of tea now.
--
I would be a paid subscriber if Taco and Hemos weren't such cunts
Evolution Inbox screenshot
Evolution Compose message screenshot
Considering the bashing Microsoft takes around these parts, isn't it surprising that the interface here has been pretty blatantly jacked from Outlook? Now it might be the case that this really *is* the best interface style to use for an E-mail client, and that's fine. But give credit where credit is due for the design, or bash and don't bite.
- Sends emails to your friends in a totally proprietary format, also encoded with CSS to protect it from the evil hackers who broke TNEF.
- In an email reply, it takes all your new text from where it should be (directly under the part replied to) and automatically moves it above the original message. This is to deliberately make you look like a newbie and thus make you more attractive to your preferred soulmate gender.
- Posts to newsgroups in Microsoft's extended RTF format. That'll teach them to complain about HTML.
- Automatically opens any executable attachments and runs them. You obviously wanted to do that, so this saves your valuable time.
- Includes a built in copy of Solitaire and Minesweeper for you to play while it sends and retrieves your mail.
- Sends me, err, 'performance data' of any *.jpg or *.mpg attachments you recieve.
What do you think? Am I on to a winner?Does my bum look big in this?
Look, we all want to see an Outlook killer on Linux. But let's face it. The reason people bitch about not having Outlook on Linux in the corporate world is mostly because of the calendaring/scheduling and collaboration type things they can do with Exchange server in the background. So, while I like the idea of having the Outlook Killer clients, when is someone going to really, really focus on the back end?
I want to see an Exchange killer in the back hooked up to one of these Outlook killer clients. Plus, I'd like to see it a little more sane/easier to administer. I'm not asking for more clickable items, I'm asking for sane permission structures (so I can keep Dave from resetting Betty's calendar without her permission), realistically tied together scheduling and a nicely followable format for the whole configuration.
I realize there are some albeit very, very small efforts under way to complete some projects along these lines. But there seems to be so much focus on the front end that no one really says squat about the server side requirements/code.
Until I hear that one of these packages is fully ready to tackle the Exchange/Outlook combo punch, I'll just keep plugging away with what I've got. Seperate server based calendaring, seperate e-mail, seperate collaboration, all a pain in the ass to accomplish, but usable. And constantly listening to my users bitch and moan because at that other company, "We used Outlook."
We get by with what we've got (and the boss liked the price tag, probably the only reason we are using Linux), but it sure would be nice to give the users something focused on their needs.
------------