I've tried several times OpenSync and SyncEvolution, and it simply made a bigger mess than anything else. Unfortunately my time didn't stretch far enough to dig into these issues.

And yes, ActiveSync seems to be the only usable alternative now. But it seems requires a bigger infrastructure. So if Zarafa can fill that gap, is easy to install and maintain I really welcome it! But I just wish the Zarafa installation and configuration could be as "easy" as Zimbra can be, with integrated anti-virus and spam filtering out-of-the-box.

I am not a sys-admin by nature, and tickling SMTP servers to do a good job just isn't my favourite cup of fun. IMAP/POP servers on the other hand are easier to setup for me. But SMTP server config - for me, that's just yuck! Which is why I like the Zimbra installation process. It works out of the box, and provide me with the tools needed to tweak just those few things I really care about. But Zimbra's open source version lacks a decent synchronisation module - and it eats memory and CPU resources.

Having that said ... Thunderbird and Lightning is a good step forward. But Lightning is still cumbersome to really use efficiently. And synching more calendars makes Lightning freeze Thunderbird for a minute when the update time has arrived. It still lacks a real killer app which really can directly compete with Outlook. Now there's just a lot of attempts of such a killer app.

Evolution is a good attempt, but the instability makes it less ideal. And I've grown fond of the user experience in Thunderbird, which fits my taste very well. Evolution just lacks the "final touch" on the user experience. And Evolution might not be ideal if you want to replace Outlook on Windows. Not sure about OSX, though.

I'd recommend taking a look at Memotoo - it's a web-based service using mainly SyncML to sync with, well, lots of things. It's worked pretty well for me so far - I had the one instance where client and server got irrepairably out of sync, and that was using SyncEvolution. It doesn't really fix the problems with existing Linux synchronisation solutions, but it does take a lot of the pain out of using them.

DAViCal allready supports CardDAV. I have seen it in action.

I provide daily DAViCal builds at http://yum.felixmoeller.de/. If you are interested in them I am more than happy to talk to you via mail.

Personally I currently operate a CalendarServer trunk snapshot. Which does all the nice stuff of sending invitations out and so on. You do not have to host any mail service yourself. Mine uses IMAP and SMTP from fastmail (needs +-addressing...).

I have a package for that too. But thats still quiet hacky therefore no public builds yet.

About changing accels on the fly, I consider that a gimp 0.x misfeature. But somehow, it has survived into GNOME3, and if you do

gsettings set org.gnome.desktop.interface

if you do

gsettings set org.gnome.desktop.interface can-change-accels true

it will still work.

That's actually not correct, the first Alt-Z opens the "Zobrazit" (View) menu and that ends circling. One has to press Esc to close the menu and then press Alt-Z again. Seems kind of broken, but better than nothing.

Thanks

IIRC part of the point of some of those projects is to develop protocols for this sort of thing (I think Diaspora is doing protocol documentation for everything new they come up with so once they get something significant going and stabilized someone could do a competing implementation)

However, that was not my main point, which is that I don't see any advantage in maintaining yet another server and creating yet another inbox I have to check separately.

So how about more typical phone-like comparison?
How is the GPS connection? With N900, GPS without an internet connection (roaming) is just plain useless, and the built in maps software is extremely slow.
Battery life?
What about actual calls? The N900 just cant decide if it wants to display the call UI is landscape or portrait, switching between each other, it frequently takes 5s till I can accept the call at all.
General UI performance? On my N900, especially rotation is extremely sluggish, as is most of the other UI, very unpleasant.

You could also install the upcoming Debian armhf port.

Yes, it can get really complicated when you have connected both mono headphones and stereo listening device, but apart from that I don't see anything that complicated.

I seriously hope you'd find a good podcast client (and blog about it :)).

I am the developer of SwallowCatcher. First of all, the release you are referring to is 0.2.0 not 2.0, i.e. it is still pre-1.0 by a long way.

Secondly, f-droid. The original version of SwallowCatcher that appeared in f-droid was pulled in by the project maintainers. They appear not to have noticed that there is a new version out. They do have a submission process via their forum, but I can't see how to create an account on their site in order to post it!

Thirdly, if you are having problems with SwallowCatcher and can reproduce them, please post an android logcat of your session, and the URL of the feed in question. This will help me debug the problem. :-)

Cheers,

Rob Connolly

I am the developer of SwallowCatcher. Thanks for mentioning my project, even if you aren't completely happy with it. I acknowledge that the software has some problems, but it is still pretty early in development. My main problem has not been with the Android platform itself, but with finding time to work on the project. My last few months have been incredibly busy and its hard to summon the energy to code in the evenings after that's what I've been doing all day at work!

Anyway, I appreciate your feedback. If we can cooperate over solving your problems than hopefully we'll end up with better software for everyone.

Cheers,

Rob Connolly

And yes, it is obvious that even f-droid repository as smoothly as it could. We'll see, hopefully this will get sorted out eventually.

mitmanek:clone $ git clone git://gitorious.org/json_diff/mainline.git json_diff
Initialized empty Git repository in /tmp/clone/json_diff/.git/
remote: Counting objects: 96, done.
remote: Compressing objects: 100% (89/89), done.
remote: Total 96 (delta 17), reused 0 (delta 0)
Receiving objects: 100% (96/96), 731.75 KiB | 508 KiB/s, done.
Resolving deltas: 100% (17/17), done.
mitmanek:clone $ cd json_diff/
mitmanek:json_diff (master) $ python json_diff.py test/old.json test/new.json 
{
    "append": {
        "c": 3, 
        "daughter": {
            "name": "Maruška"
        }
    }, 
    "remove": {
        "b": 2, 
        "son": {
            "name": "Janošek"
        }
    }, 
    "update": {
        "a": 2
    }
}
mitmanek:json_diff (master) $ 

Small complaint: The "this search" link actually ends up in "The search named all NEW has not been made visible to you."

But I am sure, exactly you can imagine a bugzilla saved query ;).

Thanks for sharing!

peace

Passion for Roses -- Peter Beales

Gmail offline was built atop WebSQLDatabase. This meant it was limited to browsers supporting WebSQLDatabase, which pointedly did not include Firefox and IE. There were two reasons WebSQLDatabase was used instead of IndexedDB:

(1) WebSQLDatabase matched up well with the existing, Gears-based implementation of offline Gmail, making porting more feasible. (This should be kind of obvious since Gears was the source of the WebSQLDatabase proposal to begin with.)
(2) IndexedDB was simply not mature enough at the time, in spec or implementation, to build a complex product like Gmail atop.

Unfortunately, when combining this with various other Gears-like needs that only Chrome implemented at the time, you got a product that only worked in Chrome.

No one on the Chrome or Gmail teams liked this state of the world, and thankfully, it's not going to continue into the indefinite future. Work on an IndexedDB-based version of offline Gmail is in progress. I don't know when it will be released, but it should allow other browsers to access offline Gmail. (Hooray!)

As for the rest of bullet 1, I can't say it seems very accurate either. We definitely still have groups and individuals that promote and talk about the open web, HTML5, etc. As for the "Chrome-first" bit, the specific cases I've seen have all been ones where the "Chrome-first"-ness is because Chrome has been first to implement some particular proposal that that app wants. This shouldn't be too hard to understand: browser vendors have finite resources and choose to focus them on different places, so generally different browsers take the lead on different standards implementations. Chrome's priorities are often informed by other app teams at Google, so it happens a lot of the time that what Chrome does first and what some app wants are related. However, to my knowledge, a lot of effort goes into ensuring that standards are being proposed, that we support other browsers when feasible to do so, etc.

I don't have the knowledge to speak to your other bullets, but I can definitively say from the Chrome/web/apps side of things that Google has not lost sight of its principles.

With Dart, the infamous "Chrome first" memo (http://pastebin.com/NUMTTrKj), Native Client, the Chrome-only Chrome app store, Google-sponsored sites that deliberately only work in Chrome (e.g. http://getcrackin.angrybird..., there's clearly a big effort on to create a universe of Chrome-only content.

Second, just to be clear: all I have all publicly available information (and certainly not all of them), so this was written mostly based on how things feel looking from outside.

Second, Mozilla did a lot of wrong decisions:
- no clear statement for or against XUL
- starting the WebSQL IndexedDB trouble
- jetpack vs. classic add-ons
- rapid release cycles with broken add-ons.

In fact, when browsing with Firefox, Google's suggestion to upgrade to a "modern browser" of course is cynical. But there is some truth in it, unfortunately.

Concerning your other points, you are just missing the information ... by following Jetpack/Add-on SDK channels I got plenty of information about XUL and Add-on SDK. And I am clearly persuaded that MoFo (and Microsoft) rejected WebSQLDB mostly on technical merits ... that as I said is unfortunate, but understandable.

Regarding the other points: Of course you get information on a technical level But there is no clear vision anymore.

You can see that Mozilla currently tries everything at once:
- browser
- mobile
- app store
- boot to gecko

Maybe they should focus a bit...

I think that's the difference though. Mozilla's mission is one about user choice and freedom and looking at the long term health of the web. So we do have to complain and sound whiny when we see huge important web companies not taking standards based development seriously and setting an example to webdevs everywhere that writing a WebSQL only website is a fine thing to do.

Google's mission on the other hand is either "Get all the information" or "Don't be evil" depending on the day. Its not "Be good!", and that gives them the freedom to do a lot more and do it quickly because its not 'evil' in the eyes of the average user. I think Mozilla's stuck in a hard place explaining that to people. Google can say things along the lines of "We love HTML so much we're going to extend it even more!" and those users are instantly confused all over again. Releasing source code, or even writing a standard and throwing it at the W3C is not enough. Standards based development is about working with other companies, which inherently means compromise and slows things down. I fear that this drive to move as fast as humanly possible will eventually kill standards entirely.

> XUL: does it have future or html5 is the only future?
Mozilla removed support for XUL in websites over a year ago. Most of what people loved about XUL is being ported to HTML5 in one way or another. Same tech. Different names.

> Your old add-on technology was deprecated and Jetpack is like copying Webkit and
> Chromium teams' decisions.
This is not true. Jetpack provides an API to make extension development easier, but the old tech hasn't been deprecated.

I'm not involved in anything Dart-related so I can't speak to that. I have no idea how compelling it is, how likely to ever be shipped in volume, etc. The "infamous" memo you cite seems to be about Dart, so I'll lump that in with Dart.

Again, if Google makes specs for Dart open, welcomes external input, and executes it in a way that allows other vendors to implement or reimplement freely, I'm not sure what's wrong with that world. Are there signs that is not happening?

As for the Chrome app store, I have asked the folks in charge of that numerous times about other browsers and how we can make sure to avoid lock-in. My impression is that while it's a difficult question, since part of the value proposition for authors is supposed to be "having a known set of target capabilities for the browser", there have been significant and ongoing talks with some Mozilla folks to try and reach a shared viewpoint on what an app is, how one is defined, the capabilities, putting them in stores, etc. I sat at at least one lunch meeting involving Mozilla folks discussing this so I know there's some truth to this. I don't know how far it goes, but the desire to collaborate seems to be present.

As for Angry Birds, I really have no idea how the contract is structured, but it strikes me that phrasing like "deliberately only work in Chrome" implies purposeful intent on Google's side to ensure the resulting experience is degraded and denied to all other browsers. In a different case that I _do_ have more specifics for, I know that what happened was that the vendor contracted to do the work came back with something that only worked in Chrome, and the team then spent the day or two before launch trying to see if they could retrofit other browser support into the product, but ultimately didn't make it. While I have no idea whether anything similar happened in this case, it seems irresponsible to me to assume and imply nefarious intent on Google's part when you don't have supporting data. Unless you have some you'd like to share.

I guess overall I feel disappointed that you're clearly frustrated, roc, because you're a smart guy, I've worked with you in the long past, and my desire is for our teams to get along well and for members of both teams to have confidence that the other team really is trying to do right by the world -- which both companies' teams are. I guarantee you that if I see things that sound like "Chrome-only", I speak up and fight them. But I really don't see all that many. I just don't subscribe to the view of the world it seems like you're convinced of.

Sorry, but that's simply not the case. If HTML5 would only have other tag names, fine. But what about the key features of XUL?
- overlays
- xbl
- localization

As for your other paragraph, I don't think you're saying anything that in any way contradicts something I said.

However, I haven't done enough research and thinking into NaCl to decide what I think about it yet, and the post itself hasn't been written yet.

I completely agree with you on the subject of browser share - it's hard to feel bad that Firefox's growth has seemingly stalled when the other story is that most people currently browse the web with a modern, performant, extensible browser. That's huge.

chrome filled the void.

So yes, to do an apples to apples comparison, fresh installs of browsers is needed and to be honest, all versions of every major browser are quite speedy at bootup when they're fresh.

BrowserId solves several headaches for developers (no complicated login systems or password storage, password reset/retrieval, etc. required) and makes life much easier for users too. That's criticial: it needs to be easier for developers AND users. And it is. There are no serious contenders that satisfy both these requirements. (OpenID has awful end-user usability.) It's win/win for all but the majors, and so should (to use evolutionary game theory terminology) invade and become the dominant strategy.

The only reason I can see this might not happen is if Mozilla fails to market it properly. This would include: not releasing a 1.0; making revisions to the API that keep breaking things; talking up the security, without pointing out how easy is it is for both website developers and users to actually use (to most people, security is boring and actually quite negative once you get past the bullet point "* It's secure!"); creating a slow login page (e.g. currently, it's far too slow!); etc.

Note: I'm not saying Mozilla has made these marketing mistakes yet --- because I assume they haven't started marketing it yet. In fact, I think the approach so far has been pretty good (i.e. deploying to Mozilla sites; simple sample code; allowing logins from a webserver rather than restricting it's usage to browsers that have implemented it; etc.) So like I said, I think you're being too pessimistic about BrowserId. I think it's future is bright.

However, in terms of EDI I don't see any future until most important governments participate and I see at least one which won't.

Anyway, to answer some of your questions, RoundCube can support multiple account with a plug-in, but not copy messages between them. The one webmail program that I found that support multiple addresses is phlymail, which has a lite version, which is open source (under MPL). I tried it some time before then forgot about it, I'm going to reinstall it in these days.

Look for example at the praise and the success that Sparrow got. It's very easy to explain: very damn fast program with unified inbox and most of the native gmail features (labels, priority inbox, fast reply, conversation view), and a (very few) extra: dropbox and facebook integration.

It just worked. Even if the search function is not very well advanced: no Boolean logic for example.

But claiming this everywhere, massively, helps a large amount of companies and individual developers. People will claim these "it could be true" "omg lets not miss the band wagon" as they're easy, small lies, that, when claimed by a large amount of people, may actually become true.

And thus, yes, gmail's and other's multi accounts still sucks hairy balls.
Mobile mail clients do work with multi account, but they're far from great.

Replace email by any other activity that requires login, it's about the same: unflexible.

Desktop apps are generally more mature in that regard.

The truth is that when I left thunderbird for Sparrow, basically none of these features where working. Conversation needed a buggy add-on and there were long blog post explaining that no-one was brave enough to look-at the more-than-outdated code of the "view pane". Even if Mo Messaging hass been founded, the project looked like it was dying, the lightning project announced for years was making very slow progress and so on…

I completely agree with you, the web-app fashion is over-hyped and there is definitely a place for standalone email clients (to take that only example). The fact that Sparrow succeeded and not Thunderbird is a proof that people don't all fell for the hype, but really that there exists a big problem with Thunderbird as it is right now.

If the Mozilla community does not want to admit it, there is no more hope in the future of Thunderbird.

Universal in the sense that they weren't geared towards one particular purpose such as communication or entertainment, and that even plain users would often implicitly use some variety of scripting or programming to make the machine a part of their natural workflow.
Independent in the sense that they could accomplish this without the processing power or storage capacity of other machines, and of course in the sense that both hardware and software would more often than not come from a variety of vendors.
Today's devices are the opposite of all that. That's why you're confused.

The new generation of users are raised not to have that impulse. You don't start with an idea, but with a software that enables you to have that idea. The means create the needs. It's not: "How do I organise my friends in convenient subgroups using Facebook?" It's: "Oh look, Google+ has circles!" It's not: "How can I make my pictures look more appealing when I publish them online?" It's: "Oh look, Instagram has filters!"

The new generation of users doesn't think of webmail as a crummy interface to a powerful system. The ideas they have about e-mail are the ones their webmail enables them to have. If their webmail can't do two accounts, then you better not have two accounts, since e-mail obviously isn't meant to do that. It's this conceptual shift that will eventually kill the personal computer and the free internet.

Well, many times to be frank ... "modern programs don't use text files, just binary data/databases", "command line is obsolete", "in future programs will be written only in C++ or Visual Basic", "Internet Explorer won and independent browsers are done".

It always expects that the current silliness will continue without regards to the real usefulness of such fad and that users are idiots who won't find out that silliness is just silly.

Also for contacts, I had the insight to add all my contacts to Google way back in case I ever lost my phone. The problem is that after importing all the contacts from my last SIM card and importing my contacts from Google, I now have duplicates of nearly every contact. It's a real pain to try deleting them, but at least the view in the contact list is the only problem (everywhere else it understands there are multiple contact names for the same number).

Last, the browser. The only two really big problems I have with it is the speed (mostly for watching Youtube videos) and the UI's features (such as settings, accessing the URL bar quickly, etc). I know the latter will eventually arrive, but I hope speed is something that's just a matter of updating the software...

Well, the biggest problem (aside from crazily small fonts) is that there is NO credentials store at all (even less the one synced via Firefox Sync, which I expected as certain to be present).

Yes confused. When I quote someone it doesn't mean I agree with him or her. It is a reference point in the discussion. I'm working on Mozilla Web compatibility Team and before that at Opera on exactly the same type of issues. :) So I share your pain, even more so that I have to try to convince on a daily basis all these web sites doing things wrong. I guess I should try to write a blog post about what I exactly do every day and the little daily frustration. It is a zen art ;)

So for me,
http://groups.google.com/d/...
redirects (eventually) to
https://groups.google.com/f...
which can be viewed in raw HTML as
https://groups.google.com/f...

Google Groups seems a perfect use-case for extreme-progressive-enhancement, but what would I know.

regards,
Sean

I will just have to repeat this here again.

Evil are created by those who think themselves are so righteous.