[Xmltv-devel] naming for SD-JSON grabber(s)

[Robert Eden]

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?

Robert

[John Veness]

Post by Robert Eden
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?
Robert

I'm only a user, not a dev, but I like your suggestion of tv_grab_zz_sdjson, assuming zz is a reserved code that will never represent a country. In particular, I approve of zz_sdjson, not zz_sd_json.

There's a question of what to call other grabbers that use the same source. I'm not sure I like zz_sdjson2 as that looks like a version 2 of the grabber, or one that connects to a version 2 API. I would prefer something like zz_sdjson_alt.

Really, though, I think it would be best if there was only one official grabber for a data source, i.e. if the developers could work together.

John

[Nick Morrott]

Post by Robert Eden
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.

Cheers,
Nick

[Robert Eden]

Post by Nick Morrott

Post by Robert Eden
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

[Karl Dietz]

Post by Robert Eden
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.

this grabber has a reversed naming scheme... The dtv in _dtv_la is the
data source, the service area is _la :-)
"Latin America Direct TV listings"

Post by Robert Eden
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.

I had a look at both grabbers and noticed that
Gary's grabber supports more features that appear useful, e.g. lineups
including the DVB triples, to allow easier setup.

As I've seen in the past there are different design philosophies for
grabbers. (serving pristine upstream data vs. massaging it for best
usability downstream) So there is room for multiple grabbers in
principle.

So I'm happy with multiple grabbers, too.

Regards,
Karl

[Ian Campbell]

Post by Robert Eden

Post by Nick Morrott
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.
[...]

I think "global" is a bit long.....

Getting well into bikeshedding here, but why does the length matter vs
clarity? It's not something that is going to get typed manually very
often (once it is working it'll be added to some script or config pane
somewhere, while setting up you'll mosdt likely just press up arrow
most of the time).

With tab completion and the current set of grabbers today it's actually
just:
'g' <TAB>
which is two characters ;-)

That is until Greece (GR), Gabon (GA) etc get grabbers when it'll
become three ('g' 'l' <tab>) until Greenland (GL) get in on the act
when it'll have to be 'g' 'l' 'o' <tab> :-D

Ian.

[John Veness]

Post by Ian Campbell

Post by Robert Eden

Post by Nick Morrott
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.
[...]

I think "global" is a bit long.....

Getting well into bikeshedding here, but why does the length matter vs
clarity? It's not something that is going to get typed manually very
often (once it is working it'll be added to some script or config pane
somewhere, while setting up you'll mosdt likely just press up arrow
most of the time).
With tab completion and the current set of grabbers today it's actually
'g' <TAB>
which is two characters ;-)
That is until Greece (GR), Gabon (GA) etc get grabbers when it'll
become three ('g' 'l' <tab>) until Greenland (GL) get in on the act
when it'll have to be 'g' 'l' 'o' <tab> :-D
Ian.

This man speaks the truth!

But if not "global", then how about "multi", for multiple countries.
That could also be used for any other grabber which does, say, two
countries, for which "global" might seem over the top.

John

[Hika van den Hoven]

Hoi John,

Post by John Veness

Post by Ian Campbell

Post by Robert Eden

Post by Nick Morrott
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.
[...]

I think "global" is a bit long.....

Getting well into bikeshedding here, but why does the length matter vs
clarity? It's not something that is going to get typed manually very
often (once it is working it'll be added to some script or config pane
somewhere, while setting up you'll mosdt likely just press up arrow
most of the time).
With tab completion and the current set of grabbers today it's actually
'g' <TAB>
which is two characters ;-)
That is until Greece (GR), Gabon (GA) etc get grabbers when it'll
become three ('g' 'l' <tab>) until Greenland (GL) get in on the act
when it'll have to be 'g' 'l' 'o' <tab> :-D
Ian.

This man speaks the truth!
But if not "global", then how about "multi", for multiple countries.
That could also be used for any other grabber which does, say, two
countries, for which "global" might seem over the top.
John

Have you even thought about the distinction between country and
language ;-)
I maintain a Dutch grabber (in Python, so not in the package) named
tv_grab_nl_py, but it also services Flemish Belgium, where they also
have a French grabber for Wallonia. Similar situations could apply to
for instance Switzerland and Canada.

Tot mails,
Hika Alina Maria van den Hoven mailto:***@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens
--

[Nick Morrott]

Post by Hika van den Hoven
Hoi John,

Post by John Veness

Post by Ian Campbell

Post by Robert Eden

Post by Nick Morrott
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.
[...]

I think "global" is a bit long.....

Getting well into bikeshedding here, but why does the length matter vs
clarity? It's not something that is going to get typed manually very
often (once it is working it'll be added to some script or config pane
somewhere, while setting up you'll mosdt likely just press up arrow
most of the time).
With tab completion and the current set of grabbers today it's actually
'g' <TAB>
which is two characters ;-)
That is until Greece (GR), Gabon (GA) etc get grabbers when it'll
become three ('g' 'l' <tab>) until Greenland (GL) get in on the act
when it'll have to be 'g' 'l' 'o' <tab> :-D
Ian.

This man speaks the truth!
But if not "global", then how about "multi", for multiple countries.
That could also be used for any other grabber which does, say, two
countries, for which "global" might seem over the top.
John

Have you even thought about the distinction between country and
language ;-)
I maintain a Dutch grabber (in Python, so not in the package) named
tv_grab_nl_py, but it also services Flemish Belgium, where they also
have a French grabber for Wallonia. Similar situations could apply to
for instance Switzerland and Canada.

How about we extend the capabilities framework that grabbers already
use and add a new (or extend an existing) capability type to add
support for languages a grabber supports/outputs?

Then an end-user could (for example) call:

$ tv_find_grabbers lang=XX_yy

and get a list of any grabbers that support their desired language.

This avoids the grabber naming scheme becoming overloaded and grabbers
having to be renamed whenever they add support for a new language.

Cheers,
Nick

[John Veness]

Post by Nick Morrott
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.

I quite like "global". It rolls off the tongue better than "zz". The only problem I have with it is that it's English-centric, but then so is "tv_grab".

John

[Karl Dietz]

Post by Nick Morrott

Post by Robert Eden
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.

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.

If we want to use two letter codes for everything, then I suggest to
just use codes from the musicbrainz list. They generally have very
well thought out guidelines on metadata. But then we should also rename
violation of that rule, maybe keeping aliases for three releases.

https://wiki.musicbrainz.org/Release_Country
XE Europe for European releases where specific country unknown
XU [Unknown Country]
XW [Worldwide]

making for tv_grab_xw_sdjson_one and tv_grab_xw_sdjson_other
I prefer a real word global/worldwide/multi. Or even better just
leaving it away to make tv_grab_sdjson_kevin and tv_grab_sdjson_gary

Lets call the grabbers tv_grab_sdjson_<suffix>

Regards,
Karl

[h***@gmail.com]

On 21 May 2016 at 07:22, Robert Eden <***@gmail.com> wrote:
[...]

Post by Robert Eden
What do folks think is a proper name for a SD-JSON grabber since it covers
so many countries?
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.

I agree. I think it's wrong to include the retrieval method in the name. Otherwise they should be called _dk_www, _br_www, _is_xml, _uk_rt_csv, _uk_atlas_json, etc. Factually accurate, but unnecessary.

Post by Robert Eden
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.

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.

Post by Robert Eden
this grabber has a reversed naming scheme... The dtv in _dtv_la is the
data source, the service area is _la :-)
"Latin America Direct TV listings"

Yes that grabber is clearly wrongly named and should be _la_dtv

Post by Robert Eden
With tab completion and the current set of grabbers today it's actually
'g' <TAB>
which is two characters ;-)

Not in Windoze it's not ;-)

Post by Robert Eden
Have you even thought about the distinction between country and
language ;-)

I believe the grabber name should relate to the 'source' and not the 'language'. A number of the grabbers allow language selection; this is done as part of the configuration. e.g. There is not a separate grabber for _dtv_la_es and _dtv_la_pt_br (since they both use the same 'source' data).

Post by Robert Eden
I quite like "global". It rolls off the tongue better than "zz".

I think 'global' should only be considered where a grabber is truly global, which, of course, none are. Otherwise it's just misleading, e.g. "yes it's global, but only covers USA, Canada, UK, Germany". Misleading IMO.



How about: tv_grab_xx_sd_file and tv_grab_xx_sd_sqlite to reflect the different caching methods (and prerequisites).

Geoff

[Robert Eden]

Post by h***@gmail.com
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.

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.

Robert

[Nick Morrott]

Post by Robert Eden

Post by h***@gmail.com
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.

Post by Robert Eden
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