Re: naming for SD-JSON grabber(s)

On 5/22/2016 9:17 PM, Nick Morrott wrote:
> On 21 May 2016 at 07:22, Robert Eden <[email protected]> wrote:
>> Howdy all..
>>
>> This discussion started on the users' list, but probably should be here.
>>
>> What do folks think is a proper name for a SD-JSON grabber since it covers
>> so many countries?
>>
>> In the thread with Gary's grabber, when I suggested moving away from NA he
>> suggested an invalid country code, like tv_grab_zz_sdjson.
>>
>> When we initially started talking about Kevin's grabber, it started using
>> tv_grab_sd_json.  Gary correctly points out it's not in Sudan.
>>
>> Kevin's grabber hasn't hit a distribution yet, so I guess it could be
>> renamed (even though there's a lot of chatter about it on the MythTV list).
>> It probably makes sense for both grabbers to be named similarly.
>>
>> Thoughts?
> I don't think we should include "json" in a new grabber's name unless
> it would otherwise conflict with an existing grabber of the same
> prefix name (e.g. if there was already a tv_grab_sd grabber) that uses
> a different data service API.
>
> A grabber's description can and should provide details of coverage,
> and could mention the data source/type if desired. As we haven't
> decided the final name yet it's difficult to say whether the "json"
> suffix would be needed for clarity or not.
>
> Namewise I'm wondering about something descriptive like
> tv_grab_global_sd (raises pinky to mouth a la Dr Evil). I'm not sold
> on the "zz" faux country code but if we want to stick to 2 letter code
> (aside from huro) there's not much wriggle room.
>
> As John mentioned in his reply, I'm also not keen on having 2 grabbers
> using the same data source's API in the XMLTV distribution. I really
> don't see the benefit for the end-user (would just add confusion IMO).
> If each have their strong points I'd prefer to see their benefits
> being rolled into a single great grabber.

If you look at most of the other grabbers, the last part of the name is 
a source description.  SD-JSON is
the name of the data source, that's why I proposed it end in SDJSON, not 
just JSON.
JSON (without the SD) is the name of a data transfer syntax and I agree 
not appropriate.  You
can't just say "SD" as there is already another data source there.

It also helps from a troubleshooting standpoint to be clear they are 
using the SD-JSON service.

I think "global" is a bit long..... the only non-two letter variant is 
dtv and that's just an extended
two letter code. :)   So, I'm leaning towards tv_grab_zz_sdjson.

I'm not sure if there's enough time to merge the grabbers... of course 
if the dependency problem
on Gary's grabber can't be fixed, too many folks won't be able to use it.

Robert





------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j