Re: Standardizing a for webapp manifests?

[Anant Narayanan]

On 9/16/12 3:29 PM, Jonas Sicking wrote:

On Fri, Sep 14, 2012 at 1:28 PM, Matt Claypotch  wrote:

In developing app testing tools, we frequently want a discovery
mechanism to let a page point to its manifest. Given that we presently
don't have a required known path to an app's manifest, I'd like to
propose we formalize an *optional*  tag that a website can use
to indicate it is an app.

I made up a sample tag on the fly for an apps hackathon shim [1]. It
looks like this:



Use cases for this include:

- Visiting the website of an app in the Gaia browser can offer to
install the site as an app
- Developer tools can identify this link to assist app developers in
testing their apps (e.g. offering to preview them in a b2g runtime)

Thoughts?


This looks great to me. I don't even have bikeshedding comments :)

Anant, is this something we can put in the current webapp-manifest drafts?


Yes! We actually supported this feature in earlier versions of WebRT, it 
was called:




(eg: 
https://github.com/mozilla/openwebapps-flickr-connector/blob/master/index.html#L7)


I have no strong opinions about app-manifest vs. application-manifest :)

Cheers,
-Anant

___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Using an array for "orientation" in manifest

[Anant Narayanan]

cvan points out in https://bugzilla.mozilla.org/show_bug.cgi?id=784574 
that using a comma-seperated list for the orientation property in the 
manifest is inconsistent with all the other fields.


I agree, as parsing a comma-seperated list is extra work, so we should 
simply use an array of strings. The behavior will remain exactly the same.


If there are no major objection, I propose we make this switch as soon 
as possible. If someone could point me to the best way to make the 
update to all the Gaia manifests in one swoop, that would be great!


Cheers,
-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Packaged App File Extension

[Anant Narayanan]

On 8/16/12 11:51 AM, Andy McKay wrote:

On 16/08/2012, at 11:40 AM, Matt Basta wrote:

- Not a generic extension (.zip)


But it is just a .zip file. I've always felt things like .xpi's didn't really 
do much, but add in a (admittedly small) layer of confusion between the file 
and its contents.


+1. I would really like to simply use .zip, not only because that's what 
they are, but because we can also effectively punt on the 
standardization question for a while.


The only reason to use a custom extension is if we expect users to 
download these files and double-click/tap to install them, but we don't 
support that on any platform at the moment.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Updating hosted apps

[Anant Narayanan]

On 08/14/2012 06:32 AM, Robert Kaiser wrote:

Anant Narayanan schrieb:

Updating packaged apps is a reasonably well-understood problem, hosted
Apps on the other hand are a bit more complicated.


Actually, for me, hosted apps feel well-understood as they (should)
follow the web paradigm of not having versioned updates but rather TTL,
just like websites do. There's some kind of cache, the contents of it
have a TTL, after that, current contents get renewed from the origin
(or, more elaborate, the origin is asked if the current content differs
from the cached content and the cache is only refreshed if so) and the
TTL "timer" starts anew. If you want to be able to avoid more edge cases
of that model, you can enable the app/site to trigger an early,
"unscheduled" cache eviction/refresh.
That's what I would expect from hosted apps, as it's the "webby" model.


The fundamental problem we are dealing with is that while the 
application itself is not versioned (just like web pages), the manifest 
that describes an application is a static file. While the manifest may 
be updated at any time by the developer, certain changes cannot be 
transparently applied.



I actually find updating of packaged apps much less understood from my
POV, as anything I can think of feels so un-webby and is another thing
that increases the rift between the "webby" model I just described and
the "not-of-the-web" packaged model. ;-)


I agree that packaged apps are not webby, however they are well 
understood in the sense that all other app stores use this model (iOS, 
Android and now even the Chrome store) and that updating a static set of 
resources in a zip file is less complex than attempting to "version" a 
live resource like a web application.


-Anant

___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Updating hosted apps

[Anant Narayanan]

On 8/9/12 4:31 PM, Rob Hudson wrote:


On Aug 9, 2012, at 4:06 PM, Anant Narayanan wrote:

- Keep polling for manifest changes in Firefox, WebRT and/or a background 
process, once a day. A HEAD request to the manifest URL should suffice.


We are also polling the manifest URL once a day on Mozilla Marketplace. If a 
developer has a very popular app with a million users, does this mean their 
server will get hit a million plus one times a day looking for manifest 
changes? If we're doing this on Mozilla Marketplace already could we use it to 
ask if there are manifest changes? It's likely not a lot of load but if we're 
already planning on hitting our servers to ask for updates for packaged apps, 
should we do the same for hosted apps and take that bit of load off the 
developer's servers?


That's a great idea. I think it makes sense to poll the marketplace 
first and then fallback to the original URL.


-Anant

___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Updating hosted apps

[Anant Narayanan]

Hey all,

Updating packaged apps is a reasonably well-understood problem, hosted 
Apps on the other hand are a bit more complicated. Our story for 
updating hosted apps has been as follows:


- The manifest includes an optional "version" field that is opaque to 
the runtime, but can be used by the developer to denote a particular 
version of the manifest.


- getSelf() can be used to retrieve this version at any point by the 
application, and an update can be triggered via install() if the 
application chooses to do so.


- Such as update will not trigger any UI *unless* the name or icon of an 
app is changed and in those cases, the user is informed of the change 
and must opt into the upgrade.


In addition to the above mechanism, AITC will update the manifest on a 
periodic basis and silently upgrade the application unless the name or 
icon changed.


Jonas identifies the following problems with the mechanism we have in 
place now:


a) The onus is on the developer to ensure that updates to the OWA 
manifest and AppCache manifest are in lock-step.


b) If a developer wants to change something like launch_path, the old 
launch_path must be kept around for an indefinite period since it is not 
possible to know when all clients have upgraded.


In order to mitigate (a), we can have the AppCache update code also 
update the OWA manifest whenever a change in the AppCache manifest is 
detected. There is no easy answer to (b), since it pretty much 
impossible to ensure manifests at all clients have been updated, so any 
solution will always break (hopefully a very small number of) clients.


I've filed https://www.bugzilla.mozilla.org/show_bug.cgi?id=781685 to 
have AppCache perform an app upgrade if necessary. I also propose we add 
the following pieces of functionality to better manage updates:


- Keep polling for manifest changes in Firefox, WebRT and/or a 
background process, once a day. A HEAD request to the manifest URL 
should suffice.


- If a change was found, a silent update can be performed if there were 
no changes to the name of icon. If the name or icon is changed, the user 
must be prompted (easy to do if the app is currently running, if not 
prompt at the next time the app is launched).


Comments, suggestions and creative ideas welcome!

-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Tracking app installs

[Anant Narayanan]

On 07/16/2012 09:50 AM, Anant Narayanan wrote:

You'll need explicit support for this from the Store to which the app is
submitted. From a technical perspective, this can be achieved using the
install_data parameter in the mozApps.install() function. That data can
later be retrieved by the app using mozApps.getSelf().


Correction: Using getSelf() to retrieve the install_data doesn't work 
yet (we only return receipts), but this functionality is being tracked 
at https://bugzilla.mozilla.org/show_bug.cgi?id=760339


In the meantime, Ian's proposal of using the manifest URL should work great.

Cheers,
-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Tracking app installs

[Anant Narayanan]

Hi David,

On 07/15/2012 08:38 PM, David wrote:

I'm keen to learn how we might track app installs by passing advertising
campaign reference in the app download link. Google Play has the ability:
https://developers.google.com/analytics/devguides/collection/android/devguid
e#google-play-tracking. Apple also has something similar but restricted to
their iAd service.


You'll need explicit support for this from the Store to which the app is 
submitted. From a technical perspective, this can be achieved using the 
install_data parameter in the mozApps.install() function. That data can 
later be retrieved by the app using mozApps.getSelf().



Also, do you have any information on how device ids will be communicated?


Same as above.

Regards,
-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Trusted apps

[Anant Narayanan]

Thanks for the detailed description, Jonas! +1 for supporting packaged apps.

On 07/09/2012 10:04 AM, Jonas Sicking wrote:

To make things more similar to how web pages normally work, we could allow
pages from app://developer.com/ to make network requests to
http://developer.com. I.e. the app would be allowed to open XMLHttpRequest
connections to http://developer.com/ myapi.cgi without
requesting any special privileges. Likewise s and s loaded from
http://developer.com would not be considered cross-origin for example for
the purposes of tainting when drawn into a . This way most of the
code which would work for a website would work in a packaged app, except
that the packaged app would have to ensure to use absolute URLs when
wanting to connect to the website.


Does this require all packaged apps to also have a "home" domain? One of 
the benefits of the packaged approach is that many kinds of developers 
will no longer have to worry about hosting web content at all, they can 
simply uploads zip files generated on their machine to various app stores.


I think it's fine to stipulate that all apps require a home domain for 
v1, if it's not in scope for B2G, but we may want to consider supporting 
domain-less apps at some point in the future.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 06/29/2012 07:14 AM, Benjamin Smedberg wrote:

1) the ability to store data. We can allow this because the user has
easy control over this by uninstalling the application
2) the ability to suppress security UI such as the location bar. We can
allow this because we tell the user at install time what domain the
content is coming from.

So in general there is nothing a webapp can do by default which can't be
undone by the user simply uninstalling the app. This is completely
different from an ActiveX install, where you have to trust that the code
won't do bad things. In general, trying a webapp *should* be as
lightweight as clicking a link.


I don't think it is, neither do I think it is realistic for us to try 
and make it so (for all kinds of apps, at-least). This becomes 
especially apparent on B2G, for sensitive apps like the dialer, SMS. For 
some other APIs like camera access, certified/trusted apps get some 
extra perks like being able to enumerate all local media devices.


In our current security model: 
https://wiki.mozilla.org/Apps/Security#Types_of_applications we have 
"installed trusted applications" and "certified applications", and these 
two definitely way beyond any normal web page. The problem is that the 
nature of a web page is at direct odds with some security requirements, 
hence the need for another conceptual wrapper: the "webapp".


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: The Reason Why Facebook’s iPhone App Is So Slow and How It’s Going to Get Blazing Fast -- Gizmodo

[Anant Narayanan]

On 06/27/2012 03:00 PM, Anant Narayanan wrote:

On 06/27/2012 12:28 PM, Kumar McMillan wrote:

This is an unfortunate message that they're sending with this article.
I'd be willing to bet a few shiny pennies that the slow part is not
the "embedded web browser" but the actual GET/POST network requests ;)
If they're re-implementing those parts in Objective C they might as
well use JavaScript. Maybe there is more to it than that.


No, unfortunately, embedded web views really *are* slow on Android &
iOS. Apple doesn't give you the shiny JITed JS engine on WebViews, and
the one on Android is derived from the default browser app, not Chrome
(though that may change once Chrome gets a larger foothold on Android).

-Anant


___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Apps security model tracking bug

[Anant Narayanan]

On 06/27/2012 07:51 AM, Lucas Adamski wrote:

I've created a meta bug to track open items for the Basecamp security model 
implementation.  You can see the entire current dependency tree here: 
https://bugzilla.mozilla.org/showdependencytree.cgi?id=764189

Note that this certainly is missing things, so if you are working on/aware of 
other bugs related to Basecamp security model for apps or B2G please add them 
to the meta bug (and nominate them for basecamp if they are not already).  
Thanks,


Thanks Lucas! We'll work on the making the appropriate changes to the 
manifest spec as well as the various validators ASAP, in addition to 
having the client enforce the fields.


-Anant

___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

Hey all,

Just summing up some IRC conversations, and our plan of action for this:

- getAll, getSelf and getInstalled will only return app objects that are 
launchable (and retain their existing semantics). For desktops, only 
apps that are "natively installed" are launchable.


- We add a new function: getNonInstalled that returns only app objects 
that are not launchable. On desktops, these are apps that have been 
acquired but not installed. On B2G, this always returns an empty set.


Felipe has graciously volunteered to get this going!

Thanks,
-Anant

___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/19/12 4:10 PM, Jonas Sicking wrote:

I'd like to avoid having .getInstalled()/.mgmt.getAll()/.getSelf()
return App objects representing an app instance which can't be launched.
The fact that Firefox will have App objects which can't be launched
seems like an implementation quirk and not something that we should
expose to the web or expect other parties to want to standardize.


In the proposal discussed, getInstalled and getSelf do not return app 
objects that can't be launched.


getAll() does. It doesn't have to, but there has to be *some* function 
that returns app object that can't be launched.



I'm even hoping that Firefox will get to the point where we don't have
such apps either. For example by automatically starting to install apps
when they are synced (in which case the App object would indicate the
installation status). That's not something we need to figure out for now
though. My point is that I think that our non-native-installed apps is
an implementation quirk that we should keep out best we can for now.


I challenge that assumption.

Let's back up here. There are two sets of apps:

- Apps I own
- Apps I have installed on my current device

I don't think we can ever merge these two sets into one. I may have 
installed AutoCAD on my desktop, but I do not want it on my phone. 
However, I would like to to be able to see the fact that I own AutoCAD 
and have it installed on my desktop, from my phone.


Automatically installing all apps I purchase on all my devices does not 
make for a great user experience, IMO. Think of getAll() as mapping to 
my purchase history, across all marketplaces.



I'm happy to use some other name than getAllSynced() though. Like
getAllNonInstalled() or getAllInstallPending().


I'm pretty agnostic about naming too. The main point is we need *two* 
functions, one that returns all the apps I have acquired across all 
marketplaces, and the other function that returns all the apps that I 
have installed on my existing device (or, alternatively a list of apps 
that I *don't* have installed on my current device).


I do not think this is an implementation quirk at all. This information 
needs to be exposed, one way or another.



I think the UA can optimize this step, since it knows which apps the
user has previously acquired, a call to install() for any of those
apps can bypass the doorhanger (we can decide whether to restrict to
privileged domains only), but no change to the API is necessary.


Ok, so we are expecting user's to go to the store an installed the app
from there? We'd just make that flow nicer by being able to link them
directly to the relevant page in the store, and not having to prompt the
user again?


Yes, I think the act of installing an app on a new device, even if it 
was already installed on another device, should be an explicit opt-in by 
the user. We can bypass the prompt, but we should not automatically 
install the app on the new device just by virtue of sync.



Also, the dashboard is expected not to display the app icons for
apps that are not installed in the same manner as those which are.
In our dashboard, at-least, there will be a clear demarcation and
such apps will displayed in a "not on this device" tab much like the
iOS store. The user can choose to install any of them on their
current device if necessary, but there were no plans to allow
seamless launching of these apps.


Sounds like having a separate functions for returning just the set of
apps which have been fully installed (in my proposal mgmt.getAll()) and
returning just the set of apps which are not natively installed (in my
proposal mgmt.getAllSynced/getAllNonInstalled/getAllInstallPending)
would work great for such a UI.


Agreed, returning the set of "installed" apps or returning the set of 
"not-installed" apps achieves exactly the same thing. We can either:


apps-installed = all-apps - apps-not-installed
or
apps-not-installed = all-apps - apps-installed

:)

-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/19/12 6:43 AM, Anant Narayanan wrote:

On 06/18/2012 06:51 PM, Jonas Sicking wrote:

Please let's not create APIs which have different meanings depending on
if the caller is privileged or not. That's just confusing to developers
and to us. And makes future extensions to such APIs even more tricky.

IMHO:
* getInstalled() should *always* just returned the list of apps
installed by the current origin.
* mgmt.getAll() should not be callable from non-privileged callers, and
for privileged callers should return any launchable app. (My
understanding is that only "natively installed" apps are launchable?)
* mgmt.getAllSynced() or some such should return any app which is in the
registry but is not launchable

Would this satisfy all requirements?


Yes, I believe it would, though I would propose a tiny tweak:
- Keep all existing functions as they behave today.
- Add mgmt.getAllInstalled() to return only the set of apps that are
installed and launchable.


I would add that we should also change getSelf/getInstalled should only 
return an app object if the app is natively installed.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 06/18/2012 06:51 PM, Jonas Sicking wrote:

Please let's not create APIs which have different meanings depending on
if the caller is privileged or not. That's just confusing to developers
and to us. And makes future extensions to such APIs even more tricky.

IMHO:
* getInstalled() should *always* just returned the list of apps
installed by the current origin.
* mgmt.getAll() should not be callable from non-privileged callers, and
for privileged callers should return any launchable app. (My
understanding is that only "natively installed" apps are launchable?)
* mgmt.getAllSynced() or some such should return any app which is in the
registry but is not launchable

Would this satisfy all requirements?


Yes, I believe it would, though I would propose a tiny tweak:
- Keep all existing functions as they behave today.
- Add mgmt.getAllInstalled() to return only the set of apps that are 
installed and launchable.


Only reason being, I want to avoid the word "synced", as the API is 
potentially useful even without sync functionality if we go by the idea 
that the DOM registry contains all acquired apps and not just installed 
apps.


Does this sound reasonable to everyone?


Do we additionally need an API which lets the a privileged app natively
install an app which has been synced but is not natively installed yet?
It seems fairly useless to users if all we can do is to tauntingly
display app icons for apps which have been synced but can't be launched
because they are not natively installed. Or are we just going to grab a
link to the store from the app and then ask the user to re-install the app?


I think the UA can optimize this step, since it knows which apps the 
user has previously acquired, a call to install() for any of those apps 
can bypass the doorhanger (we can decide whether to restrict to 
privileged domains only), but no change to the API is necessary.


Also, the dashboard is expected not to display the app icons for apps 
that are not installed in the same manner as those which are. In our 
dashboard, at-least, there will be a clear demarcation and such apps 
will displayed in a "not on this device" tab much like the iOS store. 
The user can choose to install any of them on their current device if 
necessary, but there were no plans to allow seamless launching of these 
apps.


Regards,
-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 06/18/2012 06:33 PM, Fabrice Desré wrote:

- For a non privileged page:
   - getInstalled() returns apps from this origin that are natively
installed.
   - getAll() fails.
   - getSelf() return the app only if it is "natively" installed???


Yes, getSelf will only return if natively installed since checking for 
receipts etc. is meaningless unless the user has a way to launch the app.



- For a privileged page:
   - getInstalled() returns apps from any origin that are natively installed.
   - getAll() returns apps from any origin that are in the DOM registry.
   - getSelf() returns the app if it is installed in the DOM registry???


getSelf for privileged pages behaves exactly the same as non-privileged 
page. This case is rare though, sometimes a dashboard may also be an 
app, but mostly privileged domains will get a null in the callback when 
getSelf is called.



On b2g, I guess we should consider all apps in the DOM registry as
"natively installed". Doesn't this mean that getAll() is useless, since
a dashboard will ask for privileges and thus can just use getInstalled()
to get all the apps?


That's right, which is why I mentioned in my earlier email than on B2G 
getInstalled and getAll will return the same set of apps. I think this 
behavior is fine.



I'd still like to get an explanation on why we do have to manage a
situation where the DOM registry and the natively installed apps are not
the same list.


When I'm on my mobile phone, I may not want all of my apps natively 
installed, but I'd still like to know that I own/purchased/acquired a 
particular app.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/18/12 4:37 PM, Anant Narayanan wrote:

On 6/18/12 3:22 PM, Fabrice Desré wrote:

I still don't see why we should do that. With your proposal, a Store
needs to ask to be privileged to see the "correct" list of apps, but the
call will not fail otherwise. So if the user doesn't grant the
permission, it will end up with a potentially incorrect response?


A store always gets the list of installed apps, whether or not they are
privileged - I don't think that incorrect. A store already knows whether
or not you've "acquired" the app. So what's the incorrect response here?


Oh, I apologize, I noticed an error in my original email. This line:

> - getInstalled retains its current behaviour when called from an origin
> that is not privileged (e.g. an app store).

should instead read:

- getInstalled will return the list of "natively" installed apps for an 
origin that is not privileged, but will retain the current behavior in 
the sense that only apps installed from that origin will be reported.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/18/12 3:53 PM, Ian Bicking wrote:

I don't understand how this satisfies any requirements?


Why doesn't it?


I /think/ the requirements are:

- Give a way for privileged callers to see apps that are "available" but
not "installed" (where "installed" includes meaning natively installed)


This is the difference between the set returned by getAll() and 
getInstalled() in the proposal.



- Give a way for those callers to install an available app


Possible via calling .install() on the set previously returned.


I'd suggest that getAll() be the only caller that gets available apps,
and each app has an attribute app.installed.  If false you may call
app.install() to install the application locally (and you can monitor
success with the install event).  This presumes that you do the OS/WebRT
check everytime someone calls getAll(), and for every app returned;
hopefully that can be made efficient enough?  (You can still cache results.)


An attribute on the app object is equally good. I don't feel strongly 
either way, making a change in getInstalled or adding an attribute are 
equally okay to me.


What do you find objectionable about changing getInstalled to behave 
this way, and why do you think adding a flag is a better way to do this?



If we expect application installation can be pokey and error-prone (if
it includes filling the app cache, then it could be) then we should have
a "pending" install state, so a caller can determine that while the
application isn't installed, there's no need to call app.install()
again.  And then there should probably also be some error state, so if
the installation failed the reason can be stored somewhere.  So maybe a
more complete set of functionality would be app.installState =
"available" | "installed" | "pending", app.installError = null | error
object, and maybe app.oninstallstatechange and app.oninstallprogress.
In the case of an error installError is saved (and I think should be
saved permanently until there's another attempt to install) and the
state reverts to "available" (then some sad face can be superimposed on
the app).


I believe Fabrice is already working on adding such a flag, to monitor 
progress of an app installation.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/18/12 3:22 PM, Fabrice Desré wrote:

getAll() and getInstalled() will *not* always return the same set of
apps, even in b2g. Store A will only see apps from store A using
getInstalled(), and Store B only apps from Store B, while getAll() will
list apps from Store A and Store B.


I meant in the privileged case, getAll and getInstalled will return the 
same set in B2G's case.



As for re-purposing getInstalled to act differently when called from a
privileged domain, we should consider that every other API call in the
mozApps namespace with the exception of install is context-sensitive;
and the results vary based on who the caller is. This is therefore not a
departure from the rest of the API as currently defined.


You're making an equivalence of "changing the result of a call because
the caller is privileged" (which is only true of mgmt.*) with "changing
the result depending of the caller URI" (true for getInstalled() and
getSelf()), but that are two different things.


How is a caller being privileged any different from a call being 
different based on an origin? Privilege is granted to a particular 
origin, after all. I don't agree that they are different things.



I still don't see why we should do that. With your proposal, a Store
needs to ask to be privileged to see the "correct" list of apps, but the
call will not fail otherwise. So if the user doesn't grant the
permission, it will end up with a potentially incorrect response?


A store always gets the list of installed apps, whether or not they are 
privileged - I don't think that incorrect. A store already knows whether 
or not you've "acquired" the app. So what's the incorrect response here?



Why would an app be in the DOM Registry while not natively installed? If
the reason is an implementation issue (like detecting native uninstall),
we should try to fix these issues first.


That depends on what your interpretation of the DOM registry is. My view 
is that it is a list of all the apps the user has acquired. The set of 
apps natively installed may be different (but always a subset) of that list.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

Hi all,

jst and I had a brief chat on this topic today and have the following 
proposal:


- getInstalled retains its current behaviour when called from an origin 
that is not privileged (e.g. an app store).


- getInstalled, when called from a privileged origin, will return a list 
of "natively" installed apps, where the natively-installed-or-not bit is 
determined by the WebRT which takes into context the operating system 
and other pertinent information. (In B2G, getAll and getInstalled will 
always return the same set of apps, for instance).


- getAll retains its current behaviour of returning all apps in the 
local registry and can only be accessed from a privileged domain.


As for re-purposing getInstalled to act differently when called from a 
privileged domain, we should consider that every other API call in the 
mozApps namespace with the exception of install is context-sensitive; 
and the results vary based on who the caller is. This is therefore not a 
departure from the rest of the API as currently defined.


Please send any major objections to the list. If there are none, I 
propose we move ahead with bug 749033 ASAP.


Thanks,
-Anant

___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 06/07/2012 06:16 PM, Jonas Sicking wrote:

On Jun 7, 2012 5:36 PM, "Anant Narayanan" mailto:an...@mozilla.com>> wrote:
 >> What is the purpose of this type of app? I.e. why would we want to
 >> expose an app which has been acquired but not installed anywhere?
 >
 >
 > To allow the user to (re)-install this app on their current device.
Also, it may have been installed on some other device, just not this one.

In what scenario for we need this?

The only related scenario I can think of is that a store would want to
know which apps a user has purchased, bur not currently installed. But
in this situation the store needs to keep track of which apps the user
has paid for anyway. It couldn't trust information from the browser
about which apps the user has or has not paid for.


The particular scenario we are handling right now is providing the 
ability for a user to natively install an app that they have previously 
acquired via the dashboard (on a tab named "apps not on this device" for 
instance, like the apple store interface with a similar name).


This is a slightly better user experience as it allows the user to 
natively install any previously acquired app without having to go to 
each individual store.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 06/07/2012 05:30 PM, Jonas Sicking wrote:

On Thu, Jun 7, 2012 at 11:03 AM, Anant Narayanan  wrote:

I don't think we should conflate the concept of remote apps with this API.
We can do something much simpler, there are only two "types" of apps for any
user:

1. Apps that the user has acquired, across all their devices


What is the purpose of this type of app? I.e. why would we want to
expose an app which has been acquired but not installed anywhere?


To allow the user to (re)-install this app on their current device. 
Also, it may have been installed on some other device, just not this one.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/7/12 11:17 AM, Fabrice Desré wrote:

On 06/07/2012 11:03 AM, Anant Narayanan wrote:

1. Apps that the user has acquired, across all their devices

2. Apps that are installed on the current device (the definition of
"installed" can vary from device to device, but for Android/Desktop,
this is the native installation)

My proposal is to make getAll return (1) and getInstalled return (2) in
the case of privileged domains like the dashboard. Are there use cases
that this proposal does not fulfill?


Can you launch() an app returned by getAll() but not getInstalled() ?


Since both return the same type of app object, yes.

The behavior of launching an app that is in getAll but not in 
getInstalled is left to the User-Agent (well that's a redundant 
statement, since the launch operation by itself is UA specific).


The key point is that this mechanism now lets us build dashboard that 
may want the user to install an app before being able to launch it. Not 
all dashboards may choose to enforce this, of course. A dashboard that's 
running in a non-WebRT environment (like Chrome) will simply launch the 
app in a new tab, for apps in both getAll and getInstalled sets.


For B2G, I think most apps will be in the getInstalled category, with 
the exception of new apps that was just freshly synced over from the 
cloud and have not been added to the home screen yet. One could imagine 
an interface through which the user can install these apps. It is not 
possible to launch an app that isn't on the home screen anyway [unless 
you go the dashboard in the browser app? That's pretty recursive... :)]


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/7/12 11:15 AM, Ian Bicking wrote:

The reuse of getInstalled this way seems like a pun, not a sensible
extension of the API.  getInstalled currently means "apps that this
origin installed".  It has nothing to do with any local installation
status.  mgmt.getLocallyInstalled() or some other new API is more
sensible.  Also there needs to be a way to do something with those
results, such as an .install() method on app objects, or on some app
objects.


Sure, that's what it means right now; doesn't mean we can't change what 
it means :-)


I'm just trying to arrive at the simplest possible API to give us what 
we need. We can afford to do this at this stage because we're not really 
going to break anyone using the API, as the only users right now are us 
(Mozilla).


And yes, I was thinking that calling mozApps.install() with a manifest 
URI extracted from an app object returned by getAll() would result in 
that app now appearing in the getInstalled() set - if the installation 
succeeded, of course.



RIght now getAll() is used to get 2 (even if somewhat inaccurately),
which is why I proposed a new method be added for 1 (getAllRemote()).


Same as above, I perceive this to be more of a redefinition of the 
method rather than trying to hack in extra functionality to a previously 
frozen interface (which it isn't).


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/7/12 8:56 AM, Ian Bicking wrote:

I think getInstalled is little bit of a red herring – it means "things
this site installed".  More generally, underlying mozApps is a single
list of applications that either exist (and so are installed) or don't
exist in that list.

I've been thinking about this a little, and I think it might make sense
to distinguish between applications that *could* exist (i.e., everything
in the cloud), and applications are installed locally, or installed on
other particular devices.

One thought I had is that we could have mozApps.getAllRemote() (and
getInstalledRemote()) that gives all the app objects that exist, whether
or not they are installed.  Applications objects would have a property
indicating their local install status, and an .install() method.
.uninstall() means uninstall locally.  Maybe a new method could be added
that means remove from the cloud.


I don't think we should conflate the concept of remote apps with this 
API. We can do something much simpler, there are only two "types" of 
apps for any user:


1. Apps that the user has acquired, across all their devices

2. Apps that are installed on the current device (the definition of 
"installed" can vary from device to device, but for Android/Desktop, 
this is the native installation)


My proposal is to make getAll return (1) and getInstalled return (2) in 
the case of privileged domains like the dashboard. Are there use cases 
that this proposal does not fulfill?


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/7/12 8:43 AM, Fabrice Desré wrote:

On 06/07/2012 12:57 AM, Jonas Sicking wrote:

Also, I believe that Fabrice is working on adding a property on the
App object which lets us tell the difference between an app which has
been "acquired" but not yet fully downloaded and given a launch
target. So getAllInstalled() could return all acquired apps and then
pages could filter out the ones that don't yet have a launch target.


What I'm working on in bug 702369 is the preloading of the offline-cache
at install time : this adds a property on the Application object that
let the page know the status of the app ("installed, "downloading",
"cached") and also fires onprogress on the app object when the status
changes (we'll have real progress support once bug 744713 will be fixed).


Ah, that makes sense; thanks.


What Anant and others from the apps team talk about is the difference
between an app that has been installed in the DOM Registry, and one that
has a native launcher. Unfortunately they refer to the first kind as
"acquired", and only consider the "native" one installed.

It looks like the pain point here is that there are implementation
issues with knowing when a native artifact of an app is removed from the
host OS - this leads to a situation where the app is still in the DOM
Registry but not on the host OS.

The proposed solution (changing getInstalled()) is not enough to cover
all uses cases. For instance, launch() will likely not work correctly
anymore. I really think this is an implementation issue, and that the
API is correct. Also, since we are pushing for standardization of this
API, leaking implementation details will likely not help.


How does this affect launch()?

I disagree that we are leaking any implementation details. If there are 
a significant number of platforms that, while implementing the spec 
correctly, lead to a broken user experience, then the spec needs to be 
fixed. I believe this is currently the case (i.e. we cannot implement a 
good user experience on Android and Desktop without this feature).


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 6/7/12 12:57 AM, Jonas Sicking wrote:

On Wed, Jun 6, 2012 at 10:52 PM, Anant Narayanan  wrote:

There is no way in the current API to distinguish between apps that have
been installed and apps that have been "acquired" (not quite the same as
installed) and do not have a native launch target.

Therefore the proposal is to modify getInstalled to return a list of apps
that have launch targets on the current platform, *only* when called in a
privileged context like a dashboard. getInstalled will continue to work as
currently defined for regular origins like stores.


Isn't that what the mgmt.getAllInstalled() API returns?


Do you mean getAll()? It returns all apps, even ones that have been 
acquired but don't have a launch target. For instance, if I just synced 
over an app from my desktop to mobile using apps in the cloud, it would 
show up in the getAll() list.



Also, I believe that Fabrice is working on adding a property on the
App object which lets us tell the difference between an app which has
been "acquired" but not yet fully downloaded and given a launch
target. So getAllInstalled() could return all acquired apps and then
pages could filter out the ones that don't yet have a launch target.


Hmm, that's interesting because in 
https://bugzilla.mozilla.org/show_bug.cgi?id=756306#c13 Fabrice argues 
for *not* having such a property on the app object. But if we are going 
to implement such a property, I think it will serve our purposes just 
fine and we don't have to modify the function.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Exposing an API through mozapps to understand what native apps are installed - Review and Discussion

[Anant Narayanan]

On 06/06/2012 06:54 PM, Jonas Sicking wrote:

I don't really understand what change is being proposed here. Doesn't
getInstalled already return the list of applications installed through
the store which is calling getInstalled?

In other words, what specifically is the problem with the current API?


There is no way in the current API to distinguish between apps that have 
been installed and apps that have been "acquired" (not quite the same as 
installed) and do not have a native launch target.


Therefore the proposal is to modify getInstalled to return a list of 
apps that have launch targets on the current platform, *only* when 
called in a privileged context like a dashboard. getInstalled will 
continue to work as currently defined for regular origins like stores.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 6/1/12 8:18 AM, Benjamin Smedberg wrote:

On 5/31/2012 8:41 PM, Asa Dotzler wrote:

Installing an app is not the same thing as visiting a website.

I have not yet seen a coherent description of how they are or should be
different. Technically they are exactly the same thing; when the store
"installs" an app, it is merely installing a URL link to where the app
is located. This is fundamentally different from the current android/iOS
stores, where the store actually delivers the app permanently to the
device. If the user perceives that they are getting their app from a
store when they actually are not (they are merely getting a *link* to an
app from the store!), there are going to be all sorts of disconnects
between perception and reality which could lead to unhappy users.


Clicking a link to a website is a very lightweight operation. The risk 
to the user is minimal, users may or may not like what they see after 
clicking a link, but the chances of any harm occurring is minimal. 
Additionally, no matter what the site that had the link had to say about 
the contents of the page they linked to, the user will always end up at 
the right place so they can see for themselves.


None of this is true when the user clicks an Install button. Installing 
an app is more heavyweight. It's the equivalent of the user clicking 
through an ActiveX or Java control prompt. It implies a certain level of 
trust. There might be permissions that go along with it. And the user 
cannot trust an app unless they know what it is.


Some developers may choose certain stores to faithfully represent their 
app. Others may have install pages on their own sites so they have a 
chance to tell the user what the app is about. Many others will choose 
to have no such restriction at all (and this is the default). I think we 
should enable this whole spectrum.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/31/2012 04:48 AM, Gervase Markham wrote:

What is wrong with the analogy between this facility (requiring
permission to link to an app) and requiring permission to link to a
website? If the web had started that way, it would not be the open
platform it is today.


I'm sorry, I don't know how many times I have to repeat this. But, 
installing an app is not the same as clicking a link. That is what is 
wrong with the analogy. Everyone is free to link to the install page of 
the app, wherever it might be.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/29/2012 08:34 AM, Ian Bicking wrote:

Then if you scraped the web for manifests you could link to these
install pages instead of linking directly to the manifests.  But I'm not
sure if anyone is going be scraping for bare manifest URL.

There is something a little wonky right now, that the installed app
record doesn't give you enough information to share the app with anyone
else, because the manifestURL might not be enough to install the app,
and certainly isn't a good preview of the app, and the installOrigin
just refers to the store and not the installation page.  OTOH, if we
saved the URL of the page that called navigator.mozApps.install then
that would probably fix that.


Yes, I think it might even be valuable to mandate that every app have a 
self-install page. That way, anyone wishing to link to the app can just 
point at it:


{
  "install_page": "/install.html"
}

I prefer this approach over linking to a store listing, though stores 
may have their own sharing features.


This will break down for packaged apps though, any suggestions?

-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/29/2012 03:26 AM, Gervase Markham wrote:

On 28/05/12 17:25, Anant Narayanan wrote:

Here is my proposal: we extend the manifest (if it doesn't do this
already) to clearly distinguish between free and paid apps. We then
update the spec to say that install_allowed_from is only honoured for
paid apps, as part of the mechanism to make sure the right person gets
paid.


We cannot do this unless we change the whole architecture of how apps
are installed.


Doing:

1) Having an extra mandatory parameter in a manifest with the value
"paid" or "free"; and
2) not honouring "install_allowed_from" for apps marked "free"

would require changing the entire installation architecture? I can't see
how...


Because users are unable to see either the origin (domain name) or the 
app's website at the time of install. The store is the last point at 
which a user makes a install-or-no decision.



Try and install an app from the Mozilla Marketplace,


I can't; you don't support Linux. You won't even let me try the app out
in the browser, because you have some JS which prevents me. :-(


In that case, try installing an app from 
https://apps.mozillalabs.com/appdir/ and then looking at your apps 
dashboard at https://myapps.mozillalabs.com/


Your phrasing comes off as hostile, I would have greatly preferred if 
you had used the term "we" instead of "you". We, Mozilla, are all in 
this together.



you'll see that there is no interaction between the user and the app
developer until after they've installed and run the app. The developer
is trusting the Marketplace to correctly represent their app, which is
why they chose to list there.


I can't see the connection between this point and my suggestion. Perhaps
I didn't explain my proposal well enough; see above for another attempt.


Perhaps I didn't explain myself well enough either, simply adding a 
field to the manifest is not sufficient. When you install "Favimon" for 
example, from our appdir I linked above - you are relying entirely on 
the appdir to make the decision to install the app.


Unlike a link, app installs are immediate, and done in the context of 
the page that triggered the install. The user has not had a chance to 
interact either with Favimon or its developer, and does not know what 
domain Favimon is hosted at until the app is launched.


This is very much relevant to installs_allowed_from, because developers 
(of free and paid apps) may want to restrict their app from being listed 
everywhere because they only trust certain stores to faithfully 
represent their app.


This is not a problem with hyperlinks, because irrespective of what the 
page linking to something says about that link, the user will ultimately 
land at the thing the link points to. But app installs are not hyperlinks.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/29/2012 06:42 AM, Anant Narayanan wrote:

On 05/29/2012 03:22 AM, Gervase Markham wrote:

On 28/05/12 17:06, Anant Narayanan wrote:
Let's try and get back to a high level. Do we want multiple flourishing
competing web app stores, or not? If so, don't you agree that this
feature works against that? If not, how is our store different in
approach to the Chrome, Apple or Google stores?


Yes we want multiple, flourishing competing app stores. No, this feature
does not work against that. There are several ways in which our
marketplace (and the apps ecosystem as whole) is different:


I will hasten to add that none of those were true for the Chrome store 
(only for Google's Android store). But even in the Chrome store's case, 
you have to be using Chrome to be able to use it, which isn't true for 
our marketplace.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/29/2012 03:22 AM, Gervase Markham wrote:

On 28/05/12 17:06, Anant Narayanan wrote:

Sure, let's go with this analogy. The key concept is that the
manufacturer has full control over who is able to distribute their
product.


No, they don't. They really don't. If I go to a second-hand bookstore,
the store has not had to ask permission from all the publishers before
stocking the books. If I go to my local Tesco and buy some cans of
beans, I can sell them in my shop without permission from either Tesco
or the original manufacturer of the beans. Even for non-tangible things,
First Sale says (or should say) that I can resell them without
permission of the original copyright owner. And the original
manufacturer doesn't get to set the price, or control the marketing I use.


That might be true in the UK, but in India manufacturers are free to 
distribute their product exclusively through their own retail chains, 
and it's perfectly legal. This does not apply to second-hand goods, of 
course.



Let's try and get back to a high level. Do we want multiple flourishing
competing web app stores, or not? If so, don't you agree that this
feature works against that? If not, how is our store different in
approach to the Chrome, Apple or Google stores?


Yes we want multiple, flourishing competing app stores. No, this feature 
does not work against that. There are several ways in which our 
marketplace (and the apps ecosystem as whole) is different:


- The first big difference is that in Apple or Google's case there is no 
other way in which apps can be acquired on their respective platforms, 
so neither users or developers have any choice. Our marketplace is 
simply one of many.


- A user is able to purchase an app once (from any store of their 
choosing) and run it on any of their HTML5 compliant devices.


- A user is able to choose any dashboard/appsync provider (Mozilla will 
provide one of each too). We've gone to great lengths to ensure that a 
user's list of installed apps is disjoint from any particular store.


- If a developer chooses to submit an app to our marketplace, they are 
free to use our in-app purchase system, or any other payment mechanism 
of their choosing, for both free and paid apps.


- Developers are free to choose any store to submit their app to, 
exclusively if they would like to (the default is non-exclusive).


That looks like an open app ecosystem to me.

The real competition between stores is going to be based around who can 
attract the best paid apps and that in turn will be based on how 
competitive the revenue splits will be, and is very likely to break the 
30% "industry standard" that's in place today. That's the big picture.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/28/2012 02:58 AM, Gervase Markham wrote:

If the store's HTML works on my device, and if I don't mind getting an
account with the store, and, and...

Some people don't like to get Google accounts. So they can't use the
Android market, even to get free apps written by third parties. That's
wrong - it's centralizing and controlling and unnecessary.


And I don't like that I have to sign up with Quora to read their (free) 
content. We certainly can't force people to always be open, as much as 
we'd like to. That's just the nature of the web.



Anyone can link to a Marketplace installation page.


Then why can't anyone link to the thing linked to from the Marketplace
installation page?


Because it's not a link. It's an API call: navigator.apps.install(). 
Installing an app and clicking on a hyperlink are not the same thing! If 
you think they should be, I strongly disagree, for several reasons which 
we can get into if you'd like.



Perhaps it would
make sense to let an application declare its self-installation page (or
maybe just its preferred installation page, including the Marketplace), so
if you want to do some kind of index of applications you could do so, by
simply scraping known application stores (including the Marketplace) for
manifest URLs.


I'm not quite following what you are saying here.


A store has a special relationship with the applications
you install through the store,


You seem to be assuming this, but for free apps, why does that have to
be true? I don't have a special relationship with websites I link to.
And even someone _selling_ goods in the real world doesn't necessarily
have a relationship with the manufacturer of those goods (although
someone had to have at one point).

We seem to be defaulting to control rather than openness. This is not
very webby.


That's an incorrect statement. We are defaulting to openness and 
optionally allowing developers to control how their app is distributed. 
Which is still in my book, completely orthogonal to the question of 
openness. The way to bring openness is not by forcing our view of the 
web (which is still divided even within Mozilla as is apparent from this 
thread) on everyone else who chooses to participate in our ecosystem. 
The web means a lot of different things to different people.



Why can't I create a store of "all the free task-tracking web apps I can
find"? Just like "here's a list of all the sites I like".


You can create a web page with a list of free task-tracking web apps you 
like, and users will be able to follow the links and install them, 
either via the developer's site or a store. If the developer of one of 
those apps decides to use installs_allowed_from, the only thing you 
cannot do is have an "install" button for these apps on your page, 
because he doesn't trust your site.



Here is my proposal: we extend the manifest (if it doesn't do this
already) to clearly distinguish between free and paid apps. We then
update the spec to say that install_allowed_from is only honoured for
paid apps, as part of the mechanism to make sure the right person gets paid.


We cannot do this unless we change the whole architecture of how apps 
are installed. Try and install an app from the Mozilla Marketplace, 
you'll see that there is no interaction between the user and the app 
developer until after they've installed and run the app. The developer 
is trusting the Marketplace to correctly represent their app, which is 
why they chose to list there.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/28/2012 03:03 AM, Gervase Markham wrote:

On 25/05/12 20:16, Anant Narayanan wrote:

These two are contradictory statements. The user has no way of knowing
where the app comes from by clicking an install button on a third party
page.


Surely that's a problem with our implementation and/or the spec?

Are you saying that we are coding up a system where users can install
apps without knowing where they come from?


Yes, but only if we remove the ability for developers to specify 
installs_allowed_from. In the default case, we are trusting the site 
listing the app (store, directory, etc.) to inform the user about where 
the app is coming form.



BTW, I would - and thousands of sites do. Why would you stop them?


Perhaps the Firefox analogy isn't the right one because the user
actually gets a file which is the point at which the install actually
happens and is in Mozilla's control (downloading from the website was
not "installing firefox"). To correct my earlier question, would you be
comfortable with any random website be able to control the *installer*,
and in general, the install experience for Firefox?


I'm not sure that analogy holds either. If I am a store which wants to
list "my favourite free task-tracking apps", then when the user clicks
"install" and the install process (which is run by the UA) starts, the
progress of that process is out of my hands.

A better analogy (if you ignore the "payment" component which is
necessary in the real world of physical objects) is a number of
mail-order catalogues offering the same object from the same
manufacturer. They will have different "user experiences" in the
catalogues - different photos, different write-ups, etc. - but whoever
you order from, you always get the same thing. And I think that's fine.


Sure, let's go with this analogy. The key concept is that the 
manufacturer has full control over who is able to distribute their 
product. The Internet is no different.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 5/25/12 8:43 AM, Gervase Markham wrote:
> On 24/05/12 18:29, Anant Narayanan wrote:
>> Clicking an install button is just not the same as clicking a hyperlink.
>> Context is very important for the former.
>
> The context of _where the app comes from_ is important for the former.
> The context of _where the button is_ is not important.

These two are contradictory statements. The user has no way of knowing 
where the app comes from by clicking an install button on a third party 
page.


>>>> Would you be okay with allowing any site on the internet to distribute
>>>> Firefox? I certainly wouldn't be.
>
> BTW, I would - and thousands of sites do. Why would you stop them?

Perhaps the Firefox analogy isn't the right one because the user 
actually gets a file which is the point at which the install actually 
happens and is in Mozilla's control (downloading from the website was 
not "installing firefox"). To correct my earlier question, would you be 
comfortable with any random website be able to control the *installer*, 
and in general, the install experience for Firefox?


> I'd say universal linkability is one of the key things which has made
> the web what it is today. It's very much in line with Mozilla's "no
> gatekeepers on the Internet" thing. Why would we want to go out of our
> way to break that feature for apps?

I agree that linkability is a key feature of the web and that we should 
maintain that for apps. Nobody is suggesting that we prevent people from 
linking to apps, anybody can always link the the app's page on a 
marketplace, or even better, to the developer's site itself where 
there's a big shiny install button for a self-install.


The spec disallows a *direct* install from a third party page, if the 
developer chooses to disallow it - again, the default is open. The 
distinction is important because in a direct install flow, there is the 
risk that a user will perceive that the app comes from the site they're 
at right now rather than the actual author.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 5/25/12 9:21 AM, Fabrice Desré wrote:

I don't see how ignoring installs_allowed_from is in the user's best
interest.  If it's a paid application, then ignoring
installs_allowed_from is only a way to install a non-working
application.  If it's a free application then you are going to a lot of
trouble to do something you could do already if you just went to the
right store.


"the right store" is the issue there. My understanding is that Gerv
expects free apps to not be tied to a store at all. And I agree with
him. I don't want to have to log into a store to get free apps, and be
tracked by the store when doing that. And I don't like authors being
able to prevent me to do that.


Free apps *aren't* tied to any store by default. I don't know what we're 
arguing about here. Do you want to remove the ability for developers to 
optionally restrict which stores can feature their app entirely? What 
possible gain is there in that?


Are developers not "users" for us too?


Anyone can link to a Marketplace installation page.  If the application
has its own self-installation, anyone can link to that too.  Perhaps it
would make sense to let an application declare its self-installation
page (or maybe just its preferred installation page, including the
Marketplace), so if you want to do some kind of index of applications
you could do so, by simply scraping known application stores (including
the Marketplace) for manifest URLs.  A store has a special relationship
with the applications you install through the store, but installation
and linking are different things.


What do you mean by the "Marketplace" ? Is it Mozilla store? or a
generic term?

I think we made a mistake with this field, and the only real issue is to
not let a user install apps that he won't be able to use : paid apps for
which he would have no receipt. And even that could be solved by in-apps
payment at some point (of course it's easier if the store takes care of
the payment flow).


It's not just that - how does the developer get paid for every install 
that happens elsewhere if he has no way to track that?


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 5/24/2012 9:31 AM, Benjamin Smedberg wrote:

On 5/24/2012 12:14 PM, Anant Narayanan wrote:

Why shouldn't we giving control to the developer? They are the ones
who wrote the app, why do you think we should be deciding how and
where they are acquired?

Installing a non-paid app is technically the same thing as linking to a
website. We don't provide ways for a website author to say that you may
only follow links to their website from approved sources, and in fact we
provide ways for users to suppress the referer header. I think that it's
disingenuous to say that because we are presenting websites as an app
that we should give them more control over how the user gets to them
than we do for websites...


I disagree that it's the same thing. Well, *technically* it might be the 
same, but in practice that's not how users (or developers) perceive it. 
Clicking an install button is just not the same as clicking a hyperlink. 
Context is very important for the former.



Would you be okay with allowing any site on the internet to distribute
Firefox? I certainly wouldn't be.

If Firefox were an online app available at firefox.com/app.manifest,
then Mozilla is providing Firefox, no matter how the user got it. An app
store isn't handing you an app: it's linking to an app.

You could say that users don't understand this, and they think that the
app store is actually handing them an app. But if that is the case,
however, then we should seriously rethink presenting websites as apps.
Users won't understand that their app could change at any time their
device is online without notice (unlike android or iOS apps, which are
explicitly updated).


Yes, it won't be clear at all that the app is provided by Mozilla, 
unless they dig deep and look in the about box /after/ installing the 
app. The location of the manifest is irrelevant because it is never 
shown to the user. I wouldn't want an illegitimate site to link to 
Firefox's manifest.


Of course, we can't prevent them from presenting an install button 
anyway, but we can prevent honorable user agents (most major browsers) 
to disallow such installs by baking it into the spec.


We are actively encouraging developers to not think of apps simply as 
websites, as you note, that leads to a poor user experience. Some 
websites are just bad apps (Bill noted his personal experience in the 
previous thread on WebRTs), and vice-versa.


For an app to be successful it has to be designed from the ground-up to 
behave like an app, and the best developers won't use the terms website 
and app synonymously (or so we hope!).


It's all the web under the hood, the tools and technologies are 
identical, but the design and interface of an app, as well as the 
general user experience of finding and acquiring an app is *vastly* 
different from browsing the internet and visiting web pages. I don't 
think we should be pretending that they're the same, because they're not.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 5/24/2012 9:04 AM, Benjamin Smedberg wrote:

While installs_allowed_from may be necessary for paid apps (in order to
keep people from being tricked into paying for something which they then
can't receive), it is overall a necessary evil, and if we could
distinguish in some other way between paid and nonpaid apps, we (the
Mozilla UAs) *shouldn't* honor it for nonpaid apps. In general, we
should be giving the most control to the user, not to the developer.


Why shouldn't we giving control to the developer? They are the ones who 
wrote the app, why do you think we should be deciding how and where they 
are acquired?


I'm all for giving control to the user, but in this particular instance, 
giving them control isn't really meaningful.


Would you be okay with allowing any site on the internet to distribute 
Firefox? I certainly wouldn't be.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 5/24/2012 3:43 AM, Gervase Markham wrote:

On 23/05/12 16:20, Fabrice Desre wrote:

Nothing, like for many other things you trust your UA.


But this isn't a case of "trusting" the UA - the user may well _want_
the UA to ignore such things. It's the app author who has to trust the
UA; what incentives does the UA author (who responds to the wishes of
the user, right? User control, and all that) have to respect this setting?


The user is trusting the UA to implement the apps specification correctly.


If I were writing a UA, and could reliably distinguish between free and
paid apps, I'd certainly ignore this value for free apps. More apps work
in my UA, my users are happier, the app author shouldn't care which site
pointed me at his app, I've installed it just the same way as everyone
else; everyone wins.


I think it is a flawed assumption to say "the app shouldn't care which 
site pointed me at this app", and it is not respectful for us to make 
that call on behalf of someone else.


Respecting the wishes of a developer is equally important as empowering 
the user, if developers aren't happy with the way things work, there 
would be no apps for users to install in the first place.


-Anant

___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/23/2012 12:27 PM, Mark Giffin wrote:

Anant, the current MDN docs for installs_allowed_from say the default is
this:

"If omitted, installation may be triggered only from the origin where
the app is hosted."

So what you say above means this is incorrect? I will change it.

https://developer.mozilla.org/en/Apps/Manifest


Yes, let's do that! Our current implementation certainly takes * to be 
the default value if installs_allowed_from is omitted [1].


Cheers,
-Anant

[1] https://mxr.mozilla.org/mozilla-central/source/dom/base/Webapps.js#38
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 5/23/2012 8:20 AM, Fabrice Desre wrote:

On 05/23/2012 05:17 AM, Gervase Markham wrote:

On 22/05/12 16:42, Benjamin Smedberg wrote:

Why? I think I disagree with this decision. What is different between
listing an app on a store and linking to a website? Unless you have to
pay for the app, they are fundamentally the same action. Presumably
google search can be used for apps, no?


Also, what is to stop a particular implementation from simply ignoring
install_allowed_from for free apps?


Nothing, like for many other things you trust your UA. And yes, an
add-on can also override the behavior if you want so.


Bad web crawlers also ignore robots.txt. Hopefully most users are on a 
"good" UA.


I'll draw one last analogy - we don't host add-ons on AMO without the 
authors permission, even though we may really want to :)


Cheers,
-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Dealing with manifest changes

[Anant Narayanan]

Hi all,

Yesterday we had a discussion on IRC and concluded that it would be best 
to restrict the "description" field in the manifest to 250 characters 
(the current limit is 1024). The rationale is that we can then use the 
field to populate various tooltips on launch targets, fill the short 
description field on the marketplace, etc.


A longer description of the app feels fairly store-specific and may 
include HTML, images, and so on; and thus it is best to omit such a 
field from the manifest.


The repercussion of this change is that it breaks existing manifests, 
but luckily we only have around a hundred apps on the marketplace right 
now, of which only 8 exceed the 250 character limit. So, in this 
particular instance I think we can deal with the change fairly efficiently.


It does bring up the larger question of how we will deal with changes 
that we may have to make in the future. I'd love to hear on thoughts on 
the matter!


Cheers,
-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 5/22/12 8:42 AM, Benjamin Smedberg wrote:

On 5/22/2012 11:31 AM, Anant Narayanan wrote:

On 5/22/2012 3:01 AM, Gervase Markham wrote:

On 18/05/12 22:37, Anant Narayanan wrote:

An app author is free to skip the field entirely (it is optional), or
specify "*" to allow installation from any store.


And * is the default?


Yes!


We should make sure the docs make it clear that this field is optional,
and meaningful only for paid apps.


We should document it, though I don't agree that it is meaningful only
for paid apps. If the author of a free app wishes to list it only on
specific stores, that's their decision to make.

Why? I think I disagree with this decision. What is different between
listing an app on a store and linking to a website? Unless you have to
pay for the app, they are fundamentally the same action. Presumably
google search can be used for apps, no?


Even search engines respect robots.txt. Websites already have the power 
to not be "listed" in Google. Stores should be no different.


The default is open of course, but the main point is that the final 
decision lies with the author.


Cheers,
-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 5/22/2012 3:01 AM, Gervase Markham wrote:

On 18/05/12 22:37, Anant Narayanan wrote:

An app author is free to skip the field entirely (it is optional), or
specify "*" to allow installation from any store.


And * is the default?


Yes!


We should make sure the docs make it clear that this field is optional,
and meaningful only for paid apps.


We should document it, though I don't agree that it is meaningful only 
for paid apps. If the author of a free app wishes to list it only on 
specific stores, that's their decision to make.


Cheers,
-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: "installs_allowed_from" and openness

[Anant Narayanan]

On 05/17/2012 07:40 AM, Gervase Markham wrote:

My understanding was that a principle of the "Mozilla way" of doing app
stores is that we wanted a variety of stores - anyone can set one up,
and stores would compete on ease of use, etc. We are not trying to set
up a third monopoly store alongside the iTunes store and Google Play.
For this to work, stores should be able to collect web apps and offer
them to people.

However, the manifest value "installs_allowed_from" seems to work in
entirely the opposite way; how could a new player enter the app store
space if none of the existing apps could be installed through their store?

Or have I missed something?

Could the team explain the purpose of this value? What security concern
prompted its inclusion in the manifest format?


Fabrice already covered the security concern, we give more power to the 
app developers than the app stores in this particular case. As an app 
developer, I should have full control over which stores are able to sell 
my app.


An app author is free to skip the field entirely (it is optional), or 
specify "*" to allow installation from any store.


I think this has no effect on the openness of the Apps ecosystem.

-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Re: Marketplace and non-WebRT browsers

[Anant Narayanan]

Gerv,

On 5/15/2012 2:31 AM, Gervase Markham wrote:

For quite a long time, there are going to be people out there using
browsers which do not support native integration. Firefox on Linux for
now, plus also IE, Safari, Chrome etc, plus Safari on iOS and other
platforms where Firefox is not welcome.

Our principle is "the web is the platform". What is the user experience
going to be like for users of those browsers visiting the Mozilla
Marketplace?


We support app installation on any modern browser. If a browser 
supporting the mozApps API was not found, the Marketplace falls back to 
use our shim library (include.js) which provides the same APIs as the 
"native" implementation. Any other Marketplace is also free to include 
the same shim library as a fallback.


The app should get installed in the user's dashboard (currently hosted 
at myapps.mozillalabs.com, pending a move to persona.org). If they 
aren't logged in to the dashboard, they may be prompted to login with 
their Persona -- so you'll get two logins instead of one with the HTML5 
app installation flow. But, once you are logged, launching an app is one 
click.



- If it is the plan, does it work today?


It should, if it doesn't, that's a bug; so you should let us know! I 
tested installing an app from our demo "appdir" 
(https://apps.mozillalabs.com/appdir/) and dashboard 
(https://myapps.mozillalabs.com/) on an iPhone recently, and it all 
worked as it should.


-Anant
___
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps