Re: call for release?

On Tue, 7 Jul 2015 01:57:12 +0100, Nick Morrott wrote:

>On 4 July 2015 at 09:42,  <[email protected]> wrote:
>>
>> Can we add my tv_augment to the next release? It's currently lurking in ~/beta/
>
>Thank you for factoring out the fixup code from uk_rt over into a
>useful library for other XMLTV grabber authors to use.

My pleasure - I produced it in haste last Dec when I thought we'd need something for the impending MB switch off of the RT .dat feed. So the intention was to be a drop-in replacement for your fix-ups code which could be applied to the uk_atlas feed. I.e. the end user should see no difference from what they get with uk_rt. Hence I shamelessly liberated your code (thanks!) into a new filter.


>Some thoughts:
>
>*) the perldoc comments for each "rule:" entry show an exclamation
>mark "!" as the type/fixup separator, instead of the vertical bar "|".

8-)  Oops|


>*) the ability to be able to configure the Augment library with a
>configuration hash, rather than relying on Yet Another Config File,
>would be very desirable.

Yes that's worth considering. YACF was just a Q&D solution at the time; I didn't consider alternatives.


>*) I've often wondered about adding support for regex-based rules
>(i.e. for titles containing years) to allow a single rule to be
>written instead of adding new ones each year. What does anyone else
>think?

I can't see any harm (and there's potentially a lot of benefit) in having an 'advanced' rule for people who know regex syntax. A question would be how to control (limit) its scope? I guess that would be down to the regex itself, with the user simply specifying which class of data to apply it to (i.e. 'title', 'sub-title' or 'description'). Potentially we could then allow custom regex substitution on other data in the feed like misspelt actor's names etc.? 

A poorly defined regex can have a performance impact, especially on a 14 day 300 channel data file (should people be daft enough to use such things!), but then that's the user's problem not ours.


>*) the current rules format is concise (and deliberately borrowed from
>the upstream uk_rt data files), but not exactly what anyone would call
>expressive. I'm wondering if a more structured (JSON?) layout would
>make rules easier to write for new users?

XML structured config/control files seem to be the order of the day nowadays although personally I find them major overkill (and not that easy to read) in some situations.

Cheers,
Geoff


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/