Paul Frazee pfrazee

URI handling

The "rel", "pipe", and "alias" schemes

By introducing new URI scheme behaviors, it's possible to inject user and application control into URL resolution. This can be used to compose behaviors (bash-style pipes via proxy-layering) and to simplify cross-application interactions ("Please choose a program to open this resource").

The existing schemes are http, https, httpl, and data. These core handlers are used to drive all application behavior. The additional schemes ultimately resolve to the core schemes, with the following characteristics:

"pipe": Resolves to a multipart/batch request.
"rel": Uses the navigator to resolve to an exported link.
"alias": Resolves to a URI kept in a registry.

Crosstab Transport Proxies

Shared workers can allow workers to connect to multiple documents. Leveraging this in LocalJS would allow worker-servers to bridge multiple pages, assigning different privilege levels to each connecting page.

The shared workers can run application servers. However, it might be simpler to keep apps contained in host pages, and use shared workers to house Transport Proxies. This would allow the configuration in a page to be applied on requests from other pages.

Mechanics

Transport proxies assign URIs to each connected page. To travel through, pages issue multipart/batch stack requests. This might look like:

The dashboard page includes this at init:

var serviceUA = local.agent(window.location.protocol+'//'+window.location.host);
var usersUA   = serviceUA.follow({ rel: 'gwr.io/users', link_bodies: 1 });
var sessionUA = serviceUA.follow({ rel: 'gwr.io/session', type: 'user' });

The email-update protocol was originally a direct PATCH of the user profile:

Localjs uses HTTP messaging within the page. It would be relatively simple to generate "Object servers" from the properties of JS objects.

local.addServer('foo', createObjectServer('Hello, world!'));
local.dispatch({ method: 'TOUPPERCASE', url: 'httpl://foo' }).then(function(res) {
  console.log(res.body); // => "HELLO, WORLD!"
});

In more detail, what's possible with ES5:

Workers Security Arch

The page hosts worker servers. Because workers can be user-defined, it's necessary to control which worker can do what.

Requirements

The task is to make a flexible, lightweight perm model.

Workers must define the permissions.
Perms must be transferrable.

Grimwire data environment proposals

The purpose of grimwire is to give users a way to orchestrate data and services on the Web. Here are my current ideas for how to put it together.

(my) Fixed requirements:

Has to be a web application
Has to be able to store data without a remote host
Has to interface freely with remote host services
Should make use of webrtc for private publishing/sharing

Consider the browsing history of a user to be a tree. Branches occur when they back up the history and follow new links, or when they fork tabs. Some asciiagrams:

browse: o---o---o
             \ ^back button
              o---o---o---o---o
                   \ ^new tab
                    o---o---o---o

	var utils = require('./utils');
	var server = require('../globals').server;
	var _ = require('underscore');
	var uuid = require('node-uuid');

	function makeTokenUrl(token) {
	return '/auth/tokens/'+token;
	}

	var scopePermRE = /(^[A-z0-9][A-z0-9_\-\/\.]*[A-z0-9]):(rw?)$/;

	var fn = {};
	fn.map = function(doc) {
	if (doc.is_deleted) { return; }
	if (!doc.folders) { return; }
	doc.folders.forEach(function(folder) {
	emit([folder, doc.date], doc);
	});
	};
	opts.startkey = [req.query.folder];
	opts.endkey = [req.query.folder, Number.MAX_VALUE];

	{
	rel: 'item foobar.com/rel/whatever', // reltypes
	href: 'data:application/json,{"foo":"bar"}', // any valid URI
	title: 'This is a foobar object', // ensuing metadata, can be specific to reltypes
	id: 'foobar', // id gets used a lot
	foobar_key: 'foobar_value', // using semantics in foobar.com/rel/whatever
	foobar_another_key: 'blah'
	}