It's only "open" in that they detail the spec they've come up with. Email has been so useful and resilient only because it's an open standard which is broadly agreed on and adopted.
Once the big players start adding custom features on top of existing protocols we start seeing fragmentation and parts of the market being cornered off. Once people start depending on this custom functionality, the vendor usually starts raising the walls to lock people in (see GTalk -> Hangouts.)
Yes, Google has a handful of schema.org schemas for rich snippets, structured data.[0] It's like Google's approach is to help you help them make nice search results to help you. It is definitely not some sort of proprietary thing using standardized structured data snippets.
"Once the big players start adding custom features on top of existing protocols we start seeing fragmentation and parts of the market being cornered off."
This is how innovation happens. If the experiment shows promise, it gains adoption by other vendors. This is basically how every browser advancement in the last 10 years (or more) has come around.
You're talking about some kind of neoliberal openness, where open means "the big players agreed to it and it conforms to political ideas about structure".
That's not my definition of open. My definition open is you can access the spec for free without limitation, and use, modify, and redistribute it as you see fit.
If I am feeling grandiose I will concede that openness requires not just access, but easy access and usability by all stakeholders. That's a little radical, but the point is just that there's a degree of accessibility implied in the above. If you have to crawl through a snake pit to get the source perhaps that's not really open.
But your definition, which requires buy-in from Oracle and PepsiCo in order to be "open"... I think I reject that definition.
The standard is http://json-ld.org plus https://schema.org. Client developers could freely implement it. It's a W3C standard. But don't modify it just because you can – standards don't like that.
It's annoying that google doesn't activate it for everyone, but that's like complaining about browsers allowing adblockers or SSL root certificates being tied to requirements.
> where open means "the big players agreed to it and it conforms to political ideas about structure"
That's not the 'open' part. That's the 'standard' part, where a broad consensus of all stakeholders is what ensures that it's not a mere thought experiment that lacks adoption.
I can still chat with Google users via Adium. I suppose if they're not using XMPP they're doing something else, but if Adium supports it, it's probably in libpurple, which means Pidgin and other OSS clients can do it too.
Why send the rest of the ecosystem scurrying about, chasing their tails?
And if the ecosystem gets the rug abruptly pulled out from under it one time, then how many more times will their efforts get trashed? Probably as many times as is necessary to shake them loose.
No announcements, no roadmap, no communication channel, just a sudden upgrade and everything starts timing out, or throwing errors.
Someone threw the killswitch. And they'll toggle it as often as needed, to cut out whatever the target percentage of attrition is.
That of course assumes that "serious" e-mail happens only in text-only clients.
Meanwhile, my work e-mail account is fairly busy, pretty much all HTML, and I haven't seen balloons, 96-pt text, or purple background. (I do occasionally send pink text, though. I'm that person)
And all of these markup items are highly welcome. I'd rather live in the 21st century. (Although I would kill for procmail, but we can't win them all)
It's only ever going to work for gmail users. For people who read their email in text-only clients this will never do anything.
Why not? If anything, this should been a boon for us text-only client users, since the metadata is structured in a format that can be easily parsed and displayed in an appropriate way, instead of having to deal with HTML conversions.
Having a key shortcut on Alpine to activate the main email action, instead of having to cycle over the various links, sounds great to me.
I completely agree. Having a more semantic structure rather than "anything goes" HTML can only be a good thing for the state of emailing in 2016.
Many high profile websites don't even bother sending a text/plain alternative with their emails anymore and the HTML is often cryptic when viewed from a text browser. Anything that can improve this is a good thing.
I do have a minor beef with this implementation however: at first I assumed that this metadata would be stored in custom email header (X-Mail-Action or whatever) but as far as I understand it's embedded in the HTML instead. It would make it more painful to add support for that to existing clients, especially if they use external tools to display HTML.
It's great to see that there aren't just "serious" notebook users ("this may be great for digital artists, or journalists or teachers but I'm a /serious/ professional and that's why I hate Apple").
Now there's "Serious" email, and if you don't read your email on the cli, you're just an amateur easily impressed by shiny toys.
Can't make this stuff up... Or, you know, that structured data and semantic markup are excellent for any number of "advanced" uses.
You know, incompatible with anything else, with not even API access, no third party clients and Facebook as the ultimate arbitrator of your ability to reach anyone (including your customers).
