Difference between revisions of "User:Dekarl/Static File Grabber Template"
From XMLTV
m (→Advantages: add time zone fixups) |
(be more verbose about the intent) |
||
| Line 1: | Line 1: | ||
| − | Concept of a static file grabber. | + | =Concept of a static file grabber.= |
| + | |||
| + | Some EPG services provide their data in a format that more or less resembles one big static datafile on a webserver in xmltv format. As there are some variations in the details every EPG consuming application has to add special cases for each and every guide. A grabber can turn these variants into one well defined interface allowing the interfacing of M guide services to N guide applications without writing M*N interfaces. (Thats the concept of XMLTV after all, write M+N interfaces to a common XMLTV contract instead of M*N custom ones) | ||
| + | |||
=Advantages= | =Advantages= | ||
| − | A | + | A static file grabber has some advantages over a plain [[XMLTVFormat|XMLTV file]] on the internet. |
* easy to find: a new user can find the guide source via {{program|tv_find_grabbers}} instead of having to search all over the internet | * easy to find: a new user can find the guide source via {{program|tv_find_grabbers}} instead of having to search all over the internet | ||
* easy to install: the user doesn't have to care about various means of compression nor does he have to take care of caching to easen the load on the webserver | * easy to install: the user doesn't have to care about various means of compression nor does he have to take care of caching to easen the load on the webserver | ||
| − | * easy to keep running: by going via a [[Supplementary_Files|supplementary file]] | + | * easy to keep running: by going via a [[Supplementary_Files|supplementary file]] parameters can be updated without updating xmltv itself |
| − | If you already have your guide | + | |
| − | * format conversion in the grabber instead of multiple formats on the server | + | If you already have your guide data on the internet and want to support xmltv consumers you can either adjust your service to extent your service to supply a perfectly crafted xmltv file or |
| − | * | + | * do the format conversion in the grabber instead of providing multiple formats on the server |
| + | * have the grabber convert implicit data into explicit data (e.g. time stamps in floating local time into globally understood time stamps either in UTC or local time with explicit offset) | ||
| + | * postprocess the data to follow [[Best Practice for Guides]] | ||
Latest revision as of 13:08, 13 May 2011
Concept of a static file grabber.
Some EPG services provide their data in a format that more or less resembles one big static datafile on a webserver in xmltv format. As there are some variations in the details every EPG consuming application has to add special cases for each and every guide. A grabber can turn these variants into one well defined interface allowing the interfacing of M guide services to N guide applications without writing M*N interfaces. (Thats the concept of XMLTV after all, write M+N interfaces to a common XMLTV contract instead of M*N custom ones)
Advantages
A static file grabber has some advantages over a plain XMLTV file on the internet.
- easy to find: a new user can find the guide source via tv_find_grabbers instead of having to search all over the internet
- easy to install: the user doesn't have to care about various means of compression nor does he have to take care of caching to easen the load on the webserver
- easy to keep running: by going via a supplementary file parameters can be updated without updating xmltv itself
If you already have your guide data on the internet and want to support xmltv consumers you can either adjust your service to extent your service to supply a perfectly crafted xmltv file or
- do the format conversion in the grabber instead of providing multiple formats on the server
- have the grabber convert implicit data into explicit data (e.g. time stamps in floating local time into globally understood time stamps either in UTC or local time with explicit offset)
- postprocess the data to follow Best Practice for Guides
