
Project Ballista - twapi
https://github.com/chromium/ballista/
======
Navarr
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.

~~~
bsimpson
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.

------
flashman
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](https://support.twitter.com/articles/20169421))

~~~
Mahn
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.

------
swalsh
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.

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

[http://webintents.org/](http://webintents.org/)

~~~
livingparadox
"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...](https://github.com/chromium/ballista/blob/master/docs/explainer.md#how-
is-this-different-from-other-web-interoperability-systems)

------
hartator
> 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.

~~~
calebegg
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-...](http://www.nytimes.com/2014/04/14/opinion/my-ideas-my-bosss-
property.html?_r=0)

~~~
mgiuca
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.)

------
jeswin
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.

~~~
mgiuca
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](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.

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

~~~
Khao
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.

------
omouse
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.

~~~
sowbug
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](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/](http://www.google.com/about/careers/).

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

~~~
breakingcups
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.

~~~
phonephone
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.

~~~
mgiuca
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.

