Re: naming for SD-JSON grabber(s)

On 1 June 2016 at 17:43, Robert Eden <[email protected]> wrote:
> On 6/1/2016 3:57 AM, [email protected] wrote:
>> I think that's only the case to distinguish between 2 or more grabbers
>> for the same country (e.g. _uk_rt, _uk_atlas, _uk_tvguide), but here
>> the final element represents the 'source' and not the 'method'. So for
>> the SD grabber this should be 'sd' (source) not 'json' (method).
>> Otherwise it should be tv_grab_uk_atlas_json etc. which is getting daft.
>
> SD provides two services at the moment.  SD-JSON and SD-DD (the legacy
> XML service).  That's why I like seeing SDJSON and not just SD int he
> grabber name.   I consider SDJSON the source.  We often run into
> customer support issues at SD because folks don't know which service
> they're using.
>
> I do think tv_grab_xx_sdjson_file and tv_grab_xx_sdjson_sqlite is a bit
> long, but maybe I can get used to it.  Not like folks script it a lot.

Why not call the first grabber tv_grab_xx_sdjson?

Ideally it would be best to try to get its naming stable before it
first appears in this release, rather than changing it again before
the next release.

If and when another SD-JSON grabber is committed, its naming can be
decided then.

> BTW, I assume no one is suggesting I hold off today's release to work
> this out.  If tv_grab_sd_json needs to be renamed, so be it... we need
> to get something out to deal with uk_atlas shutdown.

Ready for launch. T-14days...

Thanks,
Nick

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e