names for SD-JSON grabbers (tv_grab_sd_json, tv_grab_na_sd)

Ok, let get this discussion going so maybe we can reach a consensus.

Currently, there are two grabbers against Schedules Direct's SD-JSON 
service:
tv_grab_sd_json - Kevin's grabber add to the last distro
tv_grab_na_sd - Gary's grabber that just missed the party :)


The question was asked why have two grabbers?  The SF XMLTV project is 
mostly a collection of independent scripts. As long as scripts have met 
basic guidelines to ensure compatibility and avoid legal hassles they've 
been approved.  In this case, the two grabbers are very different.  One 
uses a memory cache and the other uses a database for storage.   If 
Kevin and Gary want to work together and maintain one grabber,  that's 
fine.  If they would rather keep their own grabbers, I don't see a 
reason not to accept both.


On to the subject of names. I think everyone agrees that tv_grab_na_sd 
needs to change.  Yes, it grabs from the same company as tv_grab_na_dd, 
but it does more than North America.

The problem folks have with tv_grab_sd_json is the SD country prefix is 
actually Sudan.   Replacing SD with "global", "glo", "gbl", or "zz" 
(invalid country) was suggested to indicate the non-country specific 
nature of the SD-JSON service.

I'll take the blame for this one, I think I suggested the name when 
Kevin's grabber was first submitted....  Now I wish I suggested 
tv_grab_zz_sdjson for the name, but what should we do going forward?  
Renaming the grabber would cause a problem for folks using it now (may 
not get updates).

I'm thinking the path of least resistance is keep tv_grab_sd_json and 
name Gary's tv_grab_sdjson. (no country section).  If we do want a 
country code I like tv_grab_zz_sdjson.. I think keeping two letters 
looks better. :)

Thoughts?

Robert




------------------------------------------------------------------------------
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.http://sdm.link/zohodev2dev