[mythtv-users] Original air date

[Gary Buhrmaster]

On Fri, Feb 28, 2020 at 10:39 PM David Engel <david at istwok.net> wrote:

> Does xmltv not have any provisions for experimental or
> grabber-specific features?  I'm thinking something along the lines of
> cpp's #pragma or X-* mail headers.  It would seem to make more sende
> to me to test a new feature first to make sure it solves the intended
> problem before changing the formal specification.

Since I am currently sheltered in place, I can get
back to part of this.....

No.  They have a validator (tv_validate_grabber)
which is part of their CI stream (I think the CI
process is currently broken), but it (used to at
least) mark any items that are emitted by a
grabber not in the DTD as invalid and fail the
grabber (it was red on the dashboard).  I
think there was even the intent that if a grabber
was red for a long long time it was removed
(I have no idea if they ever removed a grabber,
but there was the implied threat).

Quite honestly, the X- headers have sometimes
been abused to bypass formal process, resulting
in apps having to support experimental X-headers
forever, and without a formal X- registrar for the
project can lead to overlap of names causing
further confusion.

And there is also no formal "vendor space"
assignments allowing one to do anything one
wants within a more controlled namespace
(which with certain vendors in other venues
have all the same issues, but at least that
would be the vendors problem to deal between
the buildings on Tasman Drive (for those not
familiar with SNMP, there is a registered vendor
space, and Cisco has a lot of their SJ buildings
on Tasman Drive)).

That all said, there are three different ways
for experimental work that immediately come
to mind (and I have abused).  First, anyone can
write a private grabber, and see how things
work with an application that agrees on the
work.  Second, there is a cheat to abuse the
one field that has mushy interpretation, which
is "episode-num" which allows arbitrary
"systems" with arbitrary data values (it has
been abused for metadata, too), and thirdly,
as long as a grabber does not emit invalid
(unknown) elements without some explicit
configuration (so it is hidden behind something
non-standard) it can pass the CI testing.
There are a few grabbers that have some
extended configuration to do non-standard
things.

That all said, I would think that allowing a
more formal "extended" element could be a
reasonable proposal (plus points would likely
be given for a pull request for the validator
that ignores X-something or whatever entities,
and creating a registry for the "somethings"
 to insure no overlap (as has happened with
great confusion in the past)).  So I would suggest
you propose it to the XMLTV project (they
have a -devel email list too).

I will point out that the various lineup proposals
are *still* not agreed to and formalized after
nearly 10 years.  The project sometimes makes
even the IEEE or IETF look like sprinters in
standardization (hint: they are not sprinters),
but that is likely mostly because no one is
pushing for changes (I suggested last October
for a new XMLTV release to roll up the various
changes over the past period, in order to met
the Ubuntu LTS schedule and while there was
some initial effort and action, the release
managers have not done much publicly for
months (I am sure life got in the way, and just
recently someone mentioned ActivePerl on
Windows has been an issue, and TBH, right
now there are likely other priorities for many)).