It looks like a nice client- What are it's distinguishing features? What needs help? What are your intentions now- To throw it out there, or keep building it?
Are there binaries?
How are you handling the Messages in-memory? I'm looking for a mail client that can handle my multi-hundred-thousand email inbox, but everyone except Mulberry tends to have a problem ;)
Looks really sharp. Kinda reminds me of FF with the tabs at the top.
Actually with the ipad app we are not even trying to create an email client (doesn't look like it currently) but more of a email communication tool. Sounds vague but in the coming weeks things will clear up.
I'll give it another shot.
although if you have 100k+ emails in a folder, particularly a non-archive folder I'd suggest you're doing it wrong
However, you must be willing to integrate it with other tools (a frontend, something like fetchmail, and something like procmail, etc.).
but yes, if you are stuffing +100k emails into one folder -- that is completely insane -- that's why you use procmail to sort your email into different folders as it arrives; I subscribe to a LOT of email lists and ctrl-D delivers a lot of magic when I don't want to or have the time to sort through a bunch of crap but
Now I will ask the inevitable question: why did you open source it?
* We tried to do to much (classic mistake -> email + social + contacts...)
* There are way too many ways that people use e-mail (folders, labels, rules, sorting, etc, etc)
* Because there are too many ways you can not create a commercially viable alternative that fits a large nr. of users
Truth be told, we didn't even want to create an e-mail client but rather wanted to fix e-mail workflow. We never ended up being able to do that due to forementioned reasons. We intend to rectify that in a couple of our other products.
We still see a need (and people actually ask for it) for a unified e-mail/social inbox. So we thought to have the open-source community have a go at it.
> For the last one week, a considerable number of people who
> have downloaded the Inbox2 app have had issues.
> The main reason for this was that our infrastructure was not
> scaling fast enough at the rate the app was being downloaded.
Another concrete case is new email notifications. When our ipad is not the active app we simply are not able to inform you when new mail arrives (due to apple background app restrictions). With a client/cloud hybrid we can do the heavy lifting on the client and use the cloud for example to send notifications when new mail arrives.
An app can store metadata locally; no need to have that on your servers. No doubt you can do some interesting things by having a server-side infrastructure, but I'm concerned about the security implications. If your server gets hacked, an attacker would have access to all of my email. Not to mention that you would have access to all of my email and why should I trust you?
Your title implies that your hand might've been forced here. Was that the case? Would you have preferred to keep it closed?
Thank you for being design conscious. If only more developers like you existed on that platform.
Unfortunately, there's not really a good, widely used license that does what you want, mostly because you run into problems pretty quickly based on derivative works with what you want. Let's say somebody merges your email client with a browser - can they call that by a different name? Can they sell that?
Anyhow, I'd suggest looking at looking at the Apache or BSD licenses (if you want the broadest use) or the GPL (if you want to ensure that modifications to the code must be distributed with any binaries made from the code). Licenses are a bit of a pain, but you can just pick one of the common ones and it'll really help adoption.
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
It's an interesting balance between freedom and giving back - may be more suited to what you want or may not.
Just say its "public domain" or MIT or Apache in a file called license.txt in the project and forget about it.
As far as I can tell this code is not currently open source. The only permissions given are:
"now fork it, fix it and send pull requests". Which omits some important permissions, without which this cannot be called open source.
"Open-source software is software whose source code is published and made available to the public, enabling anyone to copy, modify and redistribute the source code without paying royalties or fees."
"Works are in the public domain if the intellectual property rights have expired, if the intellectual property rights are forfeited, or if they are not covered by intellectual property rights at all."
He put it on GitHub, and he announced it was Open Source on HN.
"There's no license in this case and you cannot claim any intellectual property of the code. It would be the same if you uploaded the content on your own site without providing any license. According to the terms:
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."
So, I was wrong. He has copyright.
Of course there are some places that haven't signed the Berne Convention and don't have a copyright treaty through TRIPS or something similar.
(I think -- not a lawyer)
His statement to fork, fix, and ask for pulls perhaps gives some rights, but not usage or deployment ones.
In other word, if the author intends something else, they should say so.
EDIT: just noticed ThirdParty folder -- that changes the default to whatever is compatible with the licenses asserted in these libraries. I didn't check them.
- Facebook Toolkit is Microsoft Permissive License (Ms-PL) 1.1
- FluidKit says it's the "New BSD License" but gives the old 4-clause license.
- Google/GData is Apache 2.0
- Json.NET is MIT license
- Lucene.NET Apache 2.0
- MEF is the original Microsoft Public License (Ms-PL)
- LumiSoft.Net seems to be a custom license. I'm not sure what it is
- I'm not familar enough with Mono to know what license this code is under, likely LGPL or MIT
- PyBinding: MIT
- SharpZipLib is GPL with a linking exception
- Sqlite is Public Domain
- tweetsharp: MIT
- log4net: Apache 2.0
With HttpServer, Shell32, Unrar and mshtml unknown.
"Copyright and Content Ownership
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
GitHub does not pre-screen Content, but GitHub and its designee have the right (but not the obligation) in their sole discretion to refuse or remove any Content that is available via the Service.
You shall defend GitHub against any claim, demand, suit or proceeding made or brought against GitHub by a third party alleging that Your Content, or Your use of the Service in violation of this Agreement, infringes or misappropriates the intellectual property rights of a third party or violates applicable law, and shall indemnify GitHub for any damages finally awarded against, and for reasonable attorney’s fees incurred by, GitHub in connection with any such claim, demand, suit or proceeding; provided, that GitHub (a) promptly gives You written notice of the claim, demand, suit or proceeding; (b) gives You sole control of the defense and settlement of the claim, demand, suit or proceeding (provided that You may not settle any claim, demand, suit or proceeding unless the settlement unconditionally releases GitHub of all liability); and (c) provides to You all reasonable assistance, at Your expense.
Ok, but not use or deploy the results. Basically -- the author should add a license.
"Copyright under the Berne Convention must be automatic" and "Under the Convention, copyrights for creative works are automatically in force upon their creation without being asserted or declared."
You and the other downv^Wredditors read it without considering the context.
FYI - for those looking to run this: open the non-64 bit solution, build it, then go to the installer directory and run the windows installer. Works really nicely.
I tried the new update, its definitely a little more stable but it's still bombing out on me :(
Jiangmin 13.0.900 2011.10.07 Adware/Agent.gmc
False Scan or Thread?
The thing is, I've have never quite learnt to parse raw mime email. I don't quite get the million RFC rules imposed.
And great work!
I don't always have a SSD on my computers.
1. This is written in C#, correct?
2. Two full years of your life - do you literally mean 40+ Hours/week?
If this took two full years as in 40hours/week or working on it full time, I'm shocked it took two years. SMTP, POP3, and IMAPv4 are exceedingly simple protocols and the UI just seems to look like standard controls, no custom UI elements. Just had to ask.
I know I could probably whip together a decent email client in C++ within a couple months from scratch and maybe a week or two if I used any number of libraries out there.
A full answer would take a whole book, but could you outline what part of the process was unwieldy, and what you had to rewrite as you learned more about the user experience?
In particular, since you are using WPF, would you have altered your prototyping process so that it was more user experience focussed?
Want to know how I know that you've never written an email client?
Are you planning to make a profit? Did you always intend to open source it?
Sent a pull request, by the way.
Sorry, should have mentioned it in the README, will update later