760339 - mozApps.getSelf|getInstalled|getAll only returns receipts from install_data

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Anant Narayanan [:anant]]

We added the ability to provide install_data instead of only receipts in bug 720415. However, getSelf still only returns receipts, we should also return install_data.

Comment 1

[[:fabrice] Fabrice Desré]

Note: for that to work, we need to change the IDL (see https://mxr.mozilla.org/mozilla-central/source/dom/interfaces/apps/nsIDOMApplicationRegistry.idl#17)

And we'll need to limit the max size of the install_data.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

While we are doing this, could we change getSelf to take a manifest URL as a required parameter. As far as I can tell, this is the only change we need to make to the apps API in order to support multiple apps per origin.

(We might possibly also want to rename getSelf since it can return any app from the same origin)

Comment 3

[Ian Bicking (:ianbicking)]

Note it was specifically requested (during the API redesign, I believe by Andreas Gal) that we constrain install_data to known values, instead of allowing a free-form blob of data, and that is the reason only receipts is preserved.

Comment 4

[Anant Narayanan [:anant]]

What is the reasoning behind not allowing free form data?

Comment 5

[Ian Bicking (:ianbicking)]

I can't find the bug in which it was discussed, and I think even that was incomplete – it was in part discussions between Mike Hanson and Andreas Gal.  My impression was that Andreas didn't like blobs with undefined purpose and meaning.

Comment 6

[Anant Narayanan [:anant]]

There are two more concrete cases for which we need install_data at the moment: app categories (important for native installs on Linux), and ad networks that need to pass data from the store to the app at install time so that they may be rendered with the correct click codes.

I'm fine with tackling each of these in a specific manner, but I would much rather prefer leaving install_data as an open-ended JS Object, with the appropriate size limitations. I don't fully understand the drawbacks of doing this, but we should get Andreas' input on why he thinks it is.

Comment 7

[Jason Smith [:jsmith]]

Andreas - Could address the question in comment 6?

Comment 8

[Marco Castelluccio [:marco]]

So, I'm going to take this bug, but I need comment 6 addressed.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Anant isn't working on the project anymore, so he won't be able to answer the question posed in comment 6.

But before we dig into why we made the decision and the apparent complexity involved with changing it, what is our motivation for making the change?  Anant raised two use cases in comment 6.  Are we trying to address one of them, or is there a third use case we're contemplating?

I'd much rather we pick this back up by first identifying the specific use case we want to address, as we may find that we can more easily and safely do so by returning a specific additional property of install_data.

Comment 10

[Marco Castelluccio [:marco]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #9)
> But before we dig into why we made the decision and the apparent complexity
> involved with changing it, what is our motivation for making the change? 
> Anant raised two use cases in comment 6.  Are we trying to address one of
> them, or is there a third use case we're contemplating?

An example use case could be showing the installed applications divided by category.

Comment 11

[Myk Melez [:myk] [@mykmelez]]

(In reply to Marco Castelluccio [:marco] from comment #10)
> An example use case could be showing the installed applications divided by
> category.

That's a reasonable use case, but:

1. If it's just an example, then it isn't a sufficient basis for making a general architectural change like the one requested in this bug.

2. If it's a real and present use case that we have prioritized addressing, then it might be a sufficient basis for making a general architectural change, but we should first see if there's a more specific change we could make to address the case, like returning specific properties.

And it seems like we've done exactly that in <http://hg.mozilla.org/mozilla-central/rev/c6452db09473>.


Is there another use case that is not just theoretical and which cannot be solved by a similar approach?  Or perhaps a set of them large enough to make it unfeasible to implement the one-off solutions we implemented for receipts and categories?

Comment 12

[Marco Castelluccio [:marco]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #11)
> 2. If it's a real and present use case that we have prioritized addressing,
> then it might be a sufficient basis for making a general architectural
> change, but we should first see if there's a more specific change we could
> make to address the case, like returning specific properties.
> 
> And it seems like we've done exactly that in
> <http://hg.mozilla.org/mozilla-central/rev/c6452db09473>.
> 
> 
> Is there another use case that is not just theoretical and which cannot be
> solved by a similar approach?  Or perhaps a set of them large enough to make
> it unfeasible to implement the one-off solutions we implemented for receipts
> and categories?

I was pointed to this bug when I wanted to return the category along with the receipt, because there wasn't general consensus about returning specific properties.
I'm happy with returning the category just as we do with the receipt. I mean, I don't see other use cases.

(Note that at the moment we return just the receipt and not the category: https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/AppsUtils.jsm#64)

Comment 13

[Myk Melez [:myk] [@mykmelez]]

(In reply to Marco Castelluccio [:marco] from comment #12)
> I was pointed to this bug when I wanted to return the category along with
> the receipt, because there wasn't general consensus about returning specific
> properties.

If you point me at that conversation, I'll happily weigh in on it.


> I'm happy with returning the category just as we do with the receipt. I
> mean, I don't see other use cases.

Ok, great, let's do that, then.  We can always implement the general solution (and deal with its consequences) at a later date, if it proves useful.

Comment 14

[Marco Castelluccio [:marco]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #13) 
> If you point me at that conversation, I'll happily weigh in on it.

It's in bug 760748.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.