Closed Bug 760339 Opened 7 years ago Closed 10 months ago

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

Categories

(Core Graveyard :: DOM: Apps, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: anant, Unassigned)

Details

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.
Summary: mozApps.getSelf does not return install_data → mozApps.getSelf|getInstalled|getAll only returns receipts from install_data
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.
Blocks: 760748
No longer blocks: 760748
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)
Blocks: 746465
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.
What is the reasoning behind not allowing free form data?
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.
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.
Andreas - Could address the question in comment 6?
No longer blocks: 746465
Component: DOM: Mozilla Extensions → DOM: Apps
So, I'm going to take this bug, but I need comment 6 addressed.
Flags: needinfo?(anant)
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.
Flags: needinfo?(anant)
(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.
(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?
(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)
(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.
(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.
Product: Core → Core Graveyard
Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.