chromium / ballista Goto Github PK

An interoperability system for the modern web.

License: Apache License 2.0

CSS 1.66% JavaScript 71.85% HTML 26.48%

ballista's Introduction

Ballista

Date: 2015-09-25 Updated: 2019-11-08

Ballista was a project to explore inter-website and web/native communication; specifically, communication between one website and another site or native app of the user's choosing. We explored ways for the user to be able to share or edit documents in another website or app that the first website has never even heard of, choose documents from another website, or register a website as a native file handler. We were attempting to solve similar problems to the intents system on Android, but also address other use cases like document editing. Essentially, we set out to create an interoperability system for the web.

Our explainer document dives deeper into the problem space and outlines our early draft of an API that we thought solved this problem. But this was less about proposing an API, and more about starting a conversation.

Epilogue (2019): The Ballista project started in 2015 as an ambitious exploration of the above concepts. The project evolved into a number of more specialized and smaller proposals to achieve these goals, several of which are now generally available. These include Web Share, Web Share Target and File Handling.

Spin-off proposals

These standards-track proposals were created as a result of the explorations begun in the Ballista project:

Demo

We have a prototype that works in Chrome and Firefox. Try this:

Go to handler-dot-chromium-ballista.appspot.com (Ballista Editor Demo), and click "OK" to register it as an action handler.
Go to requester-dot-chromium-ballista.appspot.com (Ballista Cloud Demo), and open a file with "Ballista Editor Demo".

These two apps don't know about each other, yet the editor can edit files from the cloud app. Using our polyfill, you can write a web app that interoperates with our demo apps in the same way.

You can view and manage app registrations at chromium-ballista.appspot.com. In the final product, the registration, picking and management UI would be part of the browser.

Resources

For a detailed overview, see Ballista Explained.
In the polyfill directory, there is a polyfill that you can use to write a requester that can fire actions at any handler, or a handler that can receive actions from any requester.
The handler and requester directories contain the source code for the demo apps described above.

See the README.md file in each directory for details. Many caveats apply.

Who is behind Ballista?

The Google Chrome team, including:

Matt Giuca <[email protected]>
Sam McNally <[email protected]>
Ben Wells <[email protected]>

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

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

ballista's People

Contributors

Stargazers

Watchers

ballista's Issues

Implement "actions" as a sequence

It seems that using an object, where the attribute names are the action verbs, as opposed to a sequence of action objects will be quite difficult to model in WebIDL if you need to do this eventually.

Could you implement the actions property like so:

{
  "name": "WebEditor",
  "short_name": "Editor",
  "icons": [...],
  "actions": [{
    "verb" : "open",                        
    "bidirectional": true,
    "types": ["text/*"]
  }]
}

Add references to previous work

How does it compare to

web intents https://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html
web wishes http://darobin.github.io/web-wish/

Expand on why registerProtocolHandler and registerProtocolHandler are a hack

The explainer says:

registerProtocolHandler and registerContentHandler: Can be used for this purpose, but it's a hack. We'd rather design an API that properly solves these use cases.

As someone new to this design and problem space, they seem perfect to me. All we need is to do some kind of push (standardization, marketing, who knows) for standardizing a few protocols, e.g. "share". You could bootstrap the ecosystem, even, by "pre-registering" all the native apps that are set up to intercept certain "intent://" URLs.

It seems like the main new feature here is the ability to use a service worker to respond in the background. But that could be achieved through extensions to register(Protocol|Content)Handler, presumably.

To be clear, I'm not trying to derail this proposal; if it has implementer interest, that's great. I just think it would be helpful for people reading through it to give a more in-depth explanation of why working with, or at least integrating with, the existing primitives of the web platform is not good enough.

Add an API for installing a handler

Currently, handlers are specified declaratively in the web manifest. This is great for indexing, but it means the browser needs to decide when to prompt the user to install a handler. (On first page load? After some time using the site? When the site is added to home screen?)

Instead, we should add an API that lets the web app programmatically request to prompt the user to install the handler. Note: The handler would still need to be declaratively specified; the API would just be a trigger to install. Then the website can provide a contextual button where the user requests to install the handler.

Downsides: We may actually want to leave the decision to browser policy (e.g., in Chrome, when the user clicks "Add to home screen" or "Add to desktop", and tie handling to app installation). This may be giving too much control to the website.

Make the files in the Ballista Cloud Demo persistent

Use IndexedDB to persist the virtual file system presented by the Ballista Cloud Demo.

Currently, all the state is stored in the foreground page's JavaScript context. By making it (locally) stateful, we can demonstrate the Ballista API's ability to receive updates while both the foreground page and service worker are dead. (Although in the latter case, our polyfill might not be able to do that...)

SW sample code in explainer doesn't deal with worker being killed

In the "edit a file" example you add event listeners while handling another event. If the service worker gets killed it will never be able to deliver that update event to the service worker since the worker doesn't re-register for th event.

More generally in all the service worker code you do asynchronous operations in event listeners, but don't call "waitUntil" on the event, so the browser will have no way of knowing that it should keep the service worker alive.