All the public apps in Marketplace have been indexed by E.me. But for Tarako, we need E.me to only show apps which are in the Tarako collection. ashort worked with e.me for the earlier implementation. So, cc'ing him on this one.

CCing Ran from E.me and jsmith just 'cause. We'll need to communicate to E.me how we are identifying apps that work with the phone in the long term - whether that's a buchet or something else. The bigger concern for our timeline is, does E.me need to make this change on the device so it would need to go out before freeze (this week?). Ran - if we have a different API URL (&tarako=yes or whatever) is that something you need to put in the build for the phone?

Wil, what is the Tarako collection? How is it indicated in the Marketplace API dumps?

Ah, the dumps. Our current prototype landing on the Tarako device on weds is going to use a collection called `tarako-apps` as it's data source (that collection isn't public yet), and then we were going to re-evaluate if we needed a separate flag or not. I don't think you've done anything with collections so that would be new code for you. I'll get some apps in that collection today so it'll show up in the dumps. I think what I'm asking is: do you need to land code on the device (meaning, this week) to adjust what is seen on the phone, or can you adjust things server side? I'm pretty sure it's server side, but I wanted to make sure.

I looked at our current dumps and it looks like it doesn't mention collections at all. I filed bug 996665 to get those in the dumps. The question in comment 3 is still valid. If the collections change is too much work on your end we could use tags or something as a stop gap.

Since we're in different timezones and I don't want to block you I went ahead and tagged all the apps that work with Tarako today as 'tarako'. They should start showing up in tomorrow's dump.

Thanks Wil. It does seem like a server only requirement. I'll have to make sure the device (or OS) identifies itself as "tarako" to the server. We're going to discuss this internally soon and fill you guys in.

Just to make sure I understand correctly: When searching on Tarako, Marketplace download suggestions should appear only if included in the "Tarako Collection". So, for instance, searching "Facebook" would normally yield the "facebook-1" app. But if it's not included in the "Tarako Collection" it should not appear to the user at all on Tarako. Yeah?

I assume category searches should stay unchanged. (Currently, when searching for a Marketplace category name, for instance "Games" or "Books", the Marketplace icon appears in search results)

Yes, it should only appear if it's in the Tarako collection. I also tagged the apps and I'd ask you do whatever is easiest as it's a temporary measure for the IOT testing next week. (Collections won't scale to 1000s of apps so we'll need another system) Does the Marketplace icon in the search results go to a specific page on the Marketplace or just launch it?

Yep, it opens the specific category page.

Short term we are going to use the tag "tarako" here to identify compatible apps. That's already in the JSON in the bulk exports - does that work for you? Long term we're going to do minimum device detection based on the new GetFeature() API. This will be similar to our current feature detection - more to come on that. Regarding the category - that's a good call out. Due to the environment we're going into, UX has recommended Tarako only has 3 categories and we're combining them on the backend before sending to the devices. See the top of https://www.dropbox.com/sh/y3zh9kg222msc2n/eGFKkPTGuq#lh:null-Marketplace%20-%20Tarako%20Screens%20-%20140407.ai . I guess the right thing to do would be to only trigger the category for those three searches (Games, Tools, Lifestyle) and in that case go directly to that category. Mathieu (needinfo'd here) will get those URLs to us shortly.

> Short term we are going to use the tag "tarako" here to identify compatible > apps. That's already in the JSON in the bulk exports - does that work for > you? Yes. I'll let you know if otherwise when implementing. > I guess the right thing to do would > be to only trigger the category for those three searches (Games, Tools, > Lifestyle) and in that case go directly to that category. Tools isn't a category we know of. Is it another label to "utilities"? I don't think the url would be relevant to us, as we open category pages using MozActivity https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/everything.me/js/etmmanager.js#L353

"Tools" is one of the new categories that aggregate existing ones (the other 2 are "Games" and "Lifestyle"). If you need to use them on the API side, pass cat=tarako-games, cat=tarako-lifestyle, or cat=tarako-tools to the existing search endpoints.

Ran - I assume you're unblocked here after comment 14. Let us know if not.

setting this to 1.3T?

Hi Wil, Can I assume if Bug 1000277 (send device model API) is done, this bug shall be done in server, and we don't need to block 1.3T, am i correct?

I don't think they are related, I hadn't seen bug 1000277 before. The short term solution to this bug is for e.me to only offer apps tagged with 'tarako' to Tarako devices (which I think is what that bug is about). The long-term solution (a few weeks from now) is for the Marketplace to write a minimum requirements library which will let us do this for all devices instead of hardcoding tags. The tagging is already done, so, this bug could likely be closed. I'd like to hear that we're good to go from Ran though.

ni? ran on comment 18

Sorry guys for the hold up. I will update you guys on all this as soon as I get new information on the implementation.

We've concluded that app filtering will be done server side by mid May. Category filtering and search query prefixes will be done client side asap.

E.me is built off of bulk dumps that include data with the required tags.

Looks like we are still listing apps in e.me which are not tagged with "tarako" gaia build identifier:20140508014002 git commit version: 8969848a STR: 1. On the latest 1.3T build, search for "linterna" in e.me 2. Notice the search results expected behavior: https://marketplace.firefox.com/app/linterna/ is not listed since it is not tagged with "tarako" https://marketplace.firefox.com/app/flashlight-linterna?src=search is listed which is tagged with "tarako" actual behavior: https://marketplace.firefox.com/app/linterna/ is listed https://marketplace.firefox.com/app/flashlight-linterna?src=search is not listed Note: Clicking on the "Download more apps"s loads Marketplace with the right app listed.

As I noted in Comment #21, we plan on updating our server with Tarako logic Mid May. I'll give an update once it's ready.

(In reply to Wil Clouser [:clouserw] from comment #15) > Ran - I assume you're unblocked here after comment 14. Let us know if not. Thanks Wil, we indeed get the Tarako tags in dumps. Will let you know if we need anything else.

E.me servers updated. Now only "tarako" tagged apps are suggested to the device. (In reply to krupa raj[:krupa] from comment #23) > expected behavior: > https://marketplace.firefox.com/app/linterna/ is not listed since it is not > tagged with "tarako" Fixed. > https://marketplace.firefox.com/app/flashlight-linterna?src=search is listed > which is tagged with "tarako" Will not show up since it's not the app name. That's unrelated search logic. Will show up searching for "Flashlight".

I think the modification is on the server side. So are there anythings else that need us to do locally?

Yep. This is a server only implementation.

See comment#28 & #29 ,this is on the server side.There is nothing need we to do.