Main Area and Open Discussion > General Software Discussion
TheBat email client v4 (early alpha) - some observations
CodeTRUCKER:
regarding nohtml inline, could you be a little more specific?
-mouser (January 24, 2008, 04:24 AM)
--- End quote ---
Sorry about that. :-[ Corrected original wording in my post; however, my questions have been addressed by Marek, except for the one about SmartBat. Well, maybe he already answered it. ;)
-CodeTRUCKER (January 24, 2008, 03:21 PM)
--- End quote ---
for 4.0, no changes are prepared for SmartBat/Scheduller except GUI changes, as I heard, scheduller improvements are planned for 4th generation, but do not when
-marek_mikus (January 24, 2008, 03:37 PM)
--- End quote ---
Thanks for the feedback! I can wait for the new implementation, but please don't fall into the trap of trying to be the "SUPER PROGRAM" that tries to be everything to everyone. Some developers have fallen into this trap and have made great apps not-so-great by doing so. TheBAT! is a great e-mail client (and getting better) and I hope it stays that way, personally. I just think the SmartBAT is sparse and a little dated, IMO, but I'll be waiting to see what Ritlabs does with it. :)
J-Mac:
...1. Problems with HTML in Pocomail/Barca on forwards or replies are not intentional, ie. it's not to "increase security", it's due to a limited viewer/editor control used. Btw. AFAIK it is getting replaced.-tamasd (January 24, 2008, 04:28 PM)
--- End quote ---
Not according to Slaven, their programmer from the beginning. He & I have discussed this countless times - he says it is for security alone. (And I disagree with him, of course!)
2. I have seen antivirus programs fail recognizing security threats in html. No protection is 100%.
--- End quote ---
I cannot say that's not true for you, but no one has ever been able to show me a real live example of it in the past five years.
Not sure, my guess is that it's way more complex to implement, and way less people use it than the POP protocol.
--- End quote ---
I don't know how true that is today, since Gmail now offers IMAP. Still, is that a valid reason? Majority rules?
Whether it's a valid or non-valid concern, depends on point of view. It certainly increases the security.
--- End quote ---
I don't really believe that. No one has offered an explanation.
Of course you can say that people shall patch their OS, always use latest up-to-date firewalls and antiviruses and antispywares and whatever, and you know what I do it, you do it, and few other people too, particularly those on this board and similar geek types. But try to see a majority user of those apps.
So IMHO it increases security (how much is another question, maybe it's just a very small increase in overall security, I don't know), but cutting down on functionality. Whether that's valid, depends on the user. You and I might hate it as we can secure our computers without having to sacrifice on functionality, but there might be others who sleep better thanks to it. (I have found several MAPI viruses discovered in 2004 and 2005 after some short search, though frankly I'm not an expert on that so I have no clue whether those threats would apply on what we are discussing.)
--- End quote ---
I don't really care if others are lax in patching their OS. Are you saying that it is the email client developers' job to protect the users who do not practice any security at the expense of other users? Oh, please! Those fools aren't using Pocomail or The Bat! anyway, right?
We are also speaking about future security. If IMAP has long history of past threats, would you now jump on it as a developer knowing that it was ok for last year or two, but not for the years before?
Anyway, I'd like to stress that I'm not supporting the "no IMAP" stance. I'm the "give me full powers, I decide" advocate.
--- End quote ---
I think you are mixing up IMAP and MAPI, true?
Jim
tamasd:
Still, is that a valid reason? Majority rules?
--- End quote ---
It's a business decision.
If you will spend a year on IMAP support, how much will it increase your sales?
Or have your client support POP, with some basic IMAP, risking some sales lost.
Note I'm not supporting their decision...you asked why those programs don't have IMAP, I offered my best guesses.
I don't really care if others are lax in patching their OS. Are you saying that it is the email client developers' job to protect the users who do not practice any security at the expense of other users? Oh, please! Those fools aren't using Pocomail or The Bat! anyway, right?
--- End quote ---
Not sure about The Bat! as it has different average user profile than Pocomail.
Generally email developers job is to decide whom to target and how to differentiate their application. Those whom Pocomail targets ("I heard somewhere that Outlook is evil" or "Outlook doesn't work for me") are more of a mainstream users that The Bat! target group. You say fools, I say majority of users.
I'm not defending them actually. Any email application shall IMHO target full email functionality. That they are a bit slow at getting there, might simply be because there is no or little money in it.
Email applications are tough business, many good clients ceased to be developed in last few years, so good decisions in terms of where to spend the development time are crucial. And it's more on the business decision (can we afford to spend the coding time on this) than the technological decision (oh we have poor support for an important part of emailing functionality like IMAP is)
I think you are mixing up IMAP and MAPI, true?
--- End quote ---
I'm sorry for the typo, of course "MAPI has a history of security threats" and it shall read that I'm not supporting their "no MAPI" stance. (Which has actually changed recently...).
They are not/were not against IMAP as far as I can tell, again I'm sorry for that typo.
Just taking too long to implement it (IMAP) fully as far as I can tell.
tamasd:
My needs are not so critical, but it is improtant for me to be able to locate specific strings in past e-mails (up to 25,000+ so far) quickly.
-CodeTRUCKER (January 24, 2008, 04:31 PM)
--- End quote ---
I'm using Archivarius. It can search both Pocomail and The Bat!, and many other way weirder formats (Zoot !). It takes a second... and that's an exageration.
superboyac:
old Microed used until 3.99 is not paragraph based, as I know, new one should be, must check this, it is implemented early.
-marek_mikus (January 24, 2008, 03:56 PM)
--- End quote ---
OK, I'll look forward to it. Right now, I'm using the regular windows editor. This is another topic, and I already started a thread about it a while back, but what's the big deal/advantage of MicroEd?
how could program detect wrapped link in plaintext? surprise me :-)
-marek_mikus (January 24, 2008, 03:56 PM)
--- End quote ---
Well, I'm not a programmer, so I'm not sure. But I'll give it a shot. If the link was detected as being one line, but wrapped, since the link doesn't have spaces in it, it should easily be able to tell that everything from "http" to the first space after that is part of a link. Now, maybe it's not possible for it to detect wrapped lines, so it would consider it two separate lines. But I don't see why it can't detect the difference between two lines and a wrapped line. Is information like that inherently lost when you send email? I know that in text editors, it's very easy to tell and preserve multiple lines vs wrapped lines.
But, let's assume the program will never be able to detect a wrapped line. Then there should be a workaround. If I highlight the whole multi-line link, there should be a context-menu item like "open selected text as hyperlink with merging". That way I can force the program to merge the multi-line content into one line even though it can't tell automatically.
Right now, it's frustrating because when that happens you have to copy the lines, paste them into a text editor, manually delete the "return" so it becomes one line, then repaste it into the web browser. This has been an issue for years with email, let's solve it already.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version