It feels like this would be a more productive conversation if you used firefox os (as well as other mobile os's) understood at a deep level the feature requirements and where you think you had a better idea suggested alternative approaches, possibly individually
<input type="file" accept="image/*> is not a sensible suggestion for a replacement on how the gallery works Applications do need access to systemXHR, the very obvious example being 'read it later' / feed reader app where the remote servers do not support CORs, email, calendar, browser probably others all have needs to talk to remote servers that are not under our control. This is fairly commonly discussed in part of the standards efforts ( https://groups.google.com/forum/#!topic/mozilla.dev.webapi/6a9QBn2Z0k4) there isnt a viable solution as yet. A feed reader / scraper that only works on the 2 servers in the world that supports CORS is not a sensible suggestion. <input type="file" accept="image/*;capture=camera"> Does not replace the camera api and is similiar to what it does already, the functionality the 'system camera service' has is not any different than the features a camera based application (like instragram) would fully expect to have. This has long been slated to be added to GUM. Being able to share data between applications, photos between the camera / gallery, contacts in various places are the result of use cases we hit against and found a requirement for. We cant just say 'replace X with an <input>' as a serious discussion about how move forward with standardisation efforts, there needs to be a deep understanding of what use cases is being fulfilled. On 17 February 2015 at 02:27, Marcos Caceres <[email protected]> wrote: > > > > 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 >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
