On February 17, 2015 at 2:26:49 AM, Benjamin Francis ([email protected])
wrote:
> On 16 February 2015 at 11:07, Marcos Caceres wrote:
>
> > > - deviceStorage:*
> >
> > Maybe the Quota Management API? I've not evaluated it, but worth having a
> > look:
> > https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html
> >
>
> I don't think this is particularly related. The underlying need of the
> Device Storage API is a cross-origin offline file store for things like
> images, audio and video which multiple apps would like to access. Is there
> a more webby way fo fulfil these use cases? How should a gallery web app
> display the photos taken by a camera web app for example?
These are great questions. I think we should find some apps that actually do
this (or want to do this), and talk more seriously about how to enable that.
> >
> > > - contacts
> >
> > There have been various attempts to do contacts - but they got caught up
> > on the whole web intents thing. I think we should redo contacts, and do it
> > right. In particular, something that allows something as simple as:
>
> I'm not convinced we need a full contacts API like the one we use in Gaia.
> If we have a dedicated storage API for contacts should we have one for
> calendars and todo list items as well? As Paul explains below, the
> underlying need here is a cross-origin offline database like DataStore.
Ok, let's bring that case to a standards body.
> Can
> we find a web-friendly way to share indexedDB databases between origins?
This is again symptomatic of how FxOS is architectured (remember that web apps
need to collaborate with native apps and system services). FxOS uses IDB to
store things, but other systems don't (e.g., iOS's photo gallery). What the
shared backing store looks like is irrelevant, just that the application can
get access to one or more images *that the user chooses to share* with the app.
> Or
> is there another way of fulfilling these use cases?
<input type="file" accept="image/*>
> How can a messaging web
> app display names next to messages for contacts whose names are stored in a
> contacts web app for example?
You can't allow direct access to people's contacts, remember:
http://venturebeat.com/2012/02/08/path-sorry-about-that-whole-data-stealing-thing/
People need to stop asking for that (or anything that looks like a shared IDB).
> How can an alternative homescreen web app
> access a list of a user's bookmarks?
A user can choose to share a particular group of bookmarks (though there is no
API for this).
> How can an alternative search app
> search the user's browsing history?
It seems extremely unlikely this would ever be allowed, for obvious reasons.
Finding the right balance between privacy and what a platform enables is key:
you can't just "I want to build all the things".
> Web Activities/web intents seem the right kind of solution to the contacts
> picker use case.
Why? I don't need a "web intent" to pick a file from my hard drive? Why would I
need one for picking a contact from my local contacts list?
> It would be great if we could make some progress
> standardising that.
Standardizing web intents probably won't be the same as standardizing contacts.
> > CORS enables SystemXHR-like capabilities on the Web. That's already a
> > solved problem.
> >
>
> I hear a lot of people saying otherwise, but I don't have a productive
> suggestion here.
I might be hard of hearing - but I've yet to see a single valid use case for a
web application to have access to this. If there are valid use cases that I'm
not aware of, we can take them to the WHATWG: The person that writes XHR that
spec (Anne van Kesteren) works for Mozilla's DOM team - and I'm sure he would
be more than happy to discuss any proposals or use cases.
> > How is basic support for things like?:
> >
> >
>
> Heh. I'm chuckling because that's exactly what the first commit to the
> camera app [1] looked like when I wrote it in 2011.
This is the confusion: the camera app is a system service - it's not a web app.
Of course camera input is not going to work there. The camera service is
*supposed enable <input type="file" accept="image/*;capture=camera">*, not the
other way around.
By design, you can't build system-level services an apps using web technology.
That's what c++, Rust, or certified-level APIs are for.
> This is a world away
> from what is needed to build apps like our camera app
Agree.
> and third party apps like Instagram.
Disagree. You don't need the same level of access as a system-level app to
build Instagram. There might be a few things missing, sure - but certainly not
at the same level as the system camera app.
> You should talk to the team who work on the camera app to
> gather some use cases of what is needed above getUserMedia, David Flanagan
> would be a good person to start with.
All input is good, but they are not building something like Instagram - they
are building a system-level application hence they need a bunch of things that
something like Instagram probably doesn't.
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
