Project Ballista | Hacker News Reader

Project Ballista

github.com

154 pointstwapi20 comments

Good!

For those unfamiliar with Android, it has a system where you send off a named Intent (I don't know the real names off hand so lets say Intent.PHONE_CALL) and another app handles it.

You might have several apps that can handle such an intent, or you have a default one - and the intent triggers that app to open and depending on various things an action to take place.

As Ballista states, they're looking at editing documents etc.

The one place where this might be creating functionality that already exists is URIs. For example, mailto:someone@somewhere.tld. Although URI's are supposed to simply indicate a resource and not really act as a full blown intent system.

Either way, things such as this bring the web closer and closer to being able to do the sort of things we "just expect" from native apps. It should be worthwhile to watch.

Intents are one of the things I've always loved about Android. I set Hangouts as my default application for phone calls and spent the summer traveling with data SIM cards in the countries I lingered in. I was able to make calls anywhere in the world for about 1MB per minute.

It worked well enough abroad that I signed up for T-Mobile's $30/5GB plan when I came back to the US. All my phone calls are routed over my data plan, and none of the apps on my phone need to know that to keep working correctly. I can open Yelp and tap Call in a restaurant listing to make a VoIP call in Hangouts just as easily as someone on a traditional plan can with the Phone app.

One benefit: I could have a "Share on Twitter" button without Twitter seeing me load their button and thus profiling me based on my web browsing?

> ...We determine the people you might enjoy following based on your visits to websites in the Twitter ecosystem (sites that have integrated Twitter buttons or widgets)... (https://support.twitter.com/articles/20169421)

Indeed, intents could address this beautifully, and even better we wouldn't need to shove a third party script for every like/share button out there, which would be a big win for the web as a whole.

This could be huge! like it's a really great idea! I'd be slightly concerned about progress slowing down as people stop implementing things because it might break someone else's implementation (kind of the thing that happens every time there's a standard) but overall it would probably make the web better instead of worse.

I wonder how this relates to Web Intents, a similar Google project from a few years back:

http://webintents.org/

"There have been several past attempts at doing this, notably Web Intents, which is no longer under development, and Mozilla's Web Activities, which is proprietary to Firefox OS and Firefox for Android."

https://github.com/chromium/ballista/blob/master/docs/explai...

> This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

I think I am more confused than anything. On the product itself, they don't seem to be aware of pajax.

Many US employers have employment agreements in which they claim default ownership of business-related intellectual property that their employees create, such as software, even when it is written on the employee's own time. Every tech company I have worked for has had one of these clauses.

I think this is what the authors are (somewhat clumsily) alluding to.

Here's some more information (it's not an ideal source, but I wasn't able to find a better one; maybe someone else will): http://www.nytimes.com/2014/04/14/opinion/my-ideas-my-bosss-...

This is not a spare-time project. It is being developed at Google by the Chromium team, but it is not an official product, just an experiment. (The disclaimer there is standard boilerplate for open source code.)

This is amazing. This is huge.

But for this to be a full success, the other vendors will also need to come on board. Can't think of a more important feature that needs standardization than intents. So once this gets standardized:

- Mozilla probably will implement, because (barring minor transgressions) they care about users more than everyone else.

- Microsoft may, because any chance of increasing their 2.5% market share depends on maximal interop and web-apps being a genuine cross-platform solution to make up for the lack of apps in their App store.

- Apple and Safari. This is going to take time, if ever. They might even come up with their own solution, requiring developers to implement two solutions to do the same thing. Strategy-wise, web apps becoming more potent is not in their interest.

I'm glad you're enthusiastic! But just to set realistic expectations: "this is less about proposing an API, and more about starting a conversation" (https://github.com/chromium/ballista). There is no guarantee that this project will go ahead, even within Chromium/Chrome.

We aren't going to standardize first, then expect buy-in from other browser vendors. We expect to have a discussion (with the web community, including web developers and browser vendors), and from there either jointly standardize/implement, or not. We won't commit to this in Chrome unless we get cooperation from the web community.

Isn't this what Ink/Filepicker tried to do?

Who?

In all seriousness, even if others tried before, they may only have failed because of having no visibility or bad marketing. This has the support of Chromium behind it, so it might be the only key point that would make this viable and adopted widely.

Interesting that the copyright is by Google yet they have permission to release it under the Apache license and yet it isn't an official Google project of any kind.

It's more common than you might think. Google has a very, uh, open attitude toward open-source hobby-project code contributions by employees.

See https://developers.google.com/open-source/projects for more, and if you'd like to come work for a company that lets you use 20% time to create new projects or contribute to existing projects, visit http://www.google.com/about/careers/.

But also note this is not a hobby project. It is a full-time project by Chromium engineers (just not an official Google product).

That distinction gets very weird. If it's a full-time project, they are working on it full time? So they are being paid by Google to develop it, they do so during regular work hours, the code is owned and released by Google, yet it is not a Google product.

I understand the point you are trying to make but at some point it becomes semantics.

I think it's important to distinguish that Google is not putting the effort that they could into this project, and that the quality of the project is not what they want you to expect out of an official Google product.

ie they want to give their engineers the ability to do neat projects—projects that could potentially make money—but they don't want to back each one fully, and they don't want to have their brand tarnished if the project fails.

Yes. We* are doing this full time during regular work hours. But this is not, yet, a product that deserves to be tied to the Google brand. It is just some code and some design documents, and hopes and dreams :)

It could fail. And even if it succeeds, it isn't ever going to be a "product", but a Web Platform feature.

*Note: I am the person leading this project.

Reply on news.ycombinator.com