platform-slug default value and syntax

[tamw-wnet]

@augustuswm @acrosman also RE https://github.com/tamw-wnet/PBS_Media_Manager_Client/issues/10

we should agree on what to do as a default argument value for 'platform-slug'. I propose 'partnerplayer'. That should most closely mirror the most common usecase. I believe that we may be able to request multiple values for 'platform-slug', eg 'partnerplayer,bento' but I am waiting for confirmation. I am almost certain that the behavior of 'platform-slug' is inclusive, so that if something is cleared for both Partner Player and Roku, requesting 'partnerplayer' will return the asset.

[augustuswm]

I am not sure on this one yet. Currently bouncing between partnerplayer as the default or some kind of "all" to get everything. Whatever it is, we should probably make the collection and individual endpoints match.

[tamw-wnet]

I'm torn too -- if we want to mirror the logical behavior of the API with our client, then neither an 'all' nor a 'partnerplayer' default would be best. If the API isn't passed a platform slug, it'll return anything that is cleared for 'allplatforms'.

So here's our options for what happens if we do not explicitly pass a platform-slug:

• no platform-slug is passed to the API, and what returns is anything cleared for 'allplatforms'
• 'partnerplayer' is passed to the API, returning anything cleared for partnerplayer (which includes anything in 'allplatforms' but also stuff that is restricted from appearing on PBS.org, bento, etc.)
• we string together a series of all available platform-slug values, eg platform-slug=bento,platform-slug=partnerplayer,platform-slug=pbsorg,platform-slug=videoportal , returning everything.

I am actually leaning towards the first option. Like I said, that mirrors the API. In practice for me, it means I would add platform-slug=partnerplayer to all of my calls, but that isn't that big a lift for me. I don't feel that strongly about the first option though.

I'm definitely up for continued discussion on this, I think we should have consensus on our choice.

[augustuswm]

I'm onboard with the first option. That is what I plan to do with our other code, leaving the platform responsibility to the consuming applications.

[acrosman]

We can work with any of the three, although I'd pick the 'partnerplayer' as the default.