I agree with Dale here.
Also, we can't afford to wait for standardization to happen to move
forward. It took *many years* to come up with a solution to the offline
issues with Service Workers. It also took years to standardize the
vibration api, which is pretty simple. I guess we should not have
implemented anything before the whatwg gatekeeper gave their approval?
Mozilla is the only significant browser vendor that doesn't have a
'native' OS. That means that all other players may have a vested
interest in keeping the web a step behind. Do we want to play this game
by abiding to consensus?
Fabrice
On 02/17/2015 02:18 AM, Dale Harvey wrote:
> 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]
> <mailto:[email protected]>> wrote:
>
>
>
>
> On February 17, 2015 at 2:26:49 AM, Benjamin Francis
> ([email protected] <mailto:[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] <mailto:[email protected]>
> https://lists.mozilla.org/listinfo/dev-b2g
>
>
>
>
> _______________________________________________
> dev-b2g mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-b2g
>
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
