I like this a lot! It makes everything *way* more decoupled and also
easier to test even :-)
The only thing that surprised me was that yes, you were using
activity:// as protocol handler. I was expecting the URL to be something
like 'whatever.gaiamobile.org' -- but I guess that might be too coupled?
However that's the most 'web like' approach I think. And with 'web like'
I mean 'not Gaia specific'. The less specificity we have, the lower the
barrier of entry :-)
sole
On 02/06/2015 15:23, Julien Wajsberg wrote:
(crossposting to dev-gaia, dev-b2g, dev-webapi,
reply-to: dev-webapi)
Hi,
In this crazy moment where we're allowed to reinvent everything, I'd
like that we take some time to think about activities.
From the start activities worked but never were quite satisfying,
especially because they use API instead of URLs, and use system messages.
Instead, we could use URLs and HTTP verbs.
We could use an URL like activity://<activity>/parameters. Gecko would
be responsible for transparently transforming this into eg
app://<app_name>/activities/<activity>/parameters (or a HTTP URL of course).
For example, instead of :
new MozActivity({
name: 'pick',
data: {
type: ['image/*', 'audio/*', 'video/*', 'text/vcard']
}
}).then(data => {
// do something with data
}).catch(e => {
// handle error
});
we could use:
fetch({
method: 'GET',
url: 'activity://pick/',
headers: new Headers({
Accept: ['image/*', 'audio/*', 'video/*', 'text/vcard'].join(',')
})
}).then(response => {
if (response.status === 404) {
// no handler for this activity
} else {
// do something with response.blob()
}
}).catch(e => {
// handle error
});
Similar things can happen for activities that share or open an element.
So instead of:
new MozActivity({
name: 'open',
data: {
type: mimetype,
filename: filename,
blob: blob,
allowSave: true
}
}).catch(e => {
// handle error
});
We could have:
fetch({
method: 'POST',
url: 'activity://open/',
headers: new Headers({
'Content-Type', mimetype
}),
parameters: new URLSearchParams({
filename: filename,
allowSave: 1
}), // I wish
body: blob
}).then(response => {
if (response.status === 404) {
// no handler for this activity
}
}).catch(e => {
// handle error
});
Then for the caller this is a lot similar.
Now for the callee this could be handled with a fetch event in a Service
Worker.
self.addEventListener('fetch', function(event) {
event.respondWith(new Promise((resolve, reject) => {
if (event.request.url.startsWith('/activity/pick')) {
resolve(ImagePicker.pickImage().then(blob => new Response(blob)));
}
}));
});
But this could just as well be handled by a server-side server.
Here are some issues I foresee:
* such a request could take long to fulfill and should not timeout,
because sometimes the request is handled by a user action.
* currently all activities come from a user action. I think we can keep
the same restriction in the ActivityProtocolHandler.
For Mozilla this would be great, because this would be a depart from
using a proprietary API.
What do you think ?
_______________________________________________
dev-webapi mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapi
--
http://soledadpenades.com
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
