Felix Domke wrote: > I'm asking myself if the "eloquence" actually makes the format (much) > more human readable than a short version. Sure you have to lookup once > how the things are layed out, but after that? Personally I like a terse format better, too. > Another thing is the speed of parsing. back in the days where we used an > XML file (the other extreme), the parsing of the channellist data was a > major part of the boot time. We're happy that this changed, and it was > probably just a bad idea to use a full xml parser for such a simple > structure. But that's the reason why i'm a bit scaried. > > Probably real world numbers will tell that it isn't as worse as i'm > currently thinking. I just hate superfluous tokens, especially when they > make the parsing slower/more painful. Not sure if they are. I also went through the xml thing and I share your experiences. But even a lowly embedded box has a few MByte/sec memory bandwidth for the CPU, so the size of the files doesn't matter that much (still, smaller is faster; try to run "wc -l" on your file, it has to scan through all data to count the \n). The slowness of xml is due to the much too complicated parser. > >>2.) well, it might be a bit conflictive with my first wish ;), but i'm > >>missing a "provider_name" entry in the sources. They might be collected > >>and replaced by a token, though. > > I was thinking of putting that sort of thing in the presets file - the > > multiplexes.conf was just for storing the raw information for locating/tuning > > each multiplex. > You're probably right, but my current understanding is that the > multiplex.conf is the direct result of doing an automatic channel scan, > i.e. more or less the contents of the SDT. > > But you're probably right, they belong elsewhere. But where? I don't > like the presets file as I want to have the preset files clean of all > automatically generated stuff. After all, it should contain just a > "collection" of services with possible attributes (like another name, > ...) I wouldn't feel good to include information which could change > (same as the service's (default) name). > > Maybe the should be put elsewhere? I vote for adding the provider_name to the service info in the multiplex file (can't think of a better place to put it). BTW, it seems this file has undefined character encoding? We should define the encoding to be utf-8. > > [... that backend parser draft...] > > I get you - sounds cool... what about a structure containing a set of callback > > function pointers though? I think it might make the parser easier than doing > > it line by line. > I generally don't like callbacks, as i don't like libraries which make > any assumptions about the program flow. > > But generally, it would be the same thing, just a different layout. > > The advantage is that you don't need any context pointers (a "void *" > probably does the thing, anyway), you don't need to declare (essentially > wrapper) functions for the stuff, and you know on the first view that > the program flow doesn't leave this loop. I like the parser backend API, too. > >>3.) Favourites. > >>What do you think about this? > > Ooh, I hadn't thought about using a directory structure to store that stuff. > > The reason I hadn't implemented presets was that I wasn't entirely happy with > > the file format and wanted to think about it. > > My current idea is a simplistic structure like fine > > Wouldn't using lots of wee files be bad though? You'd prolly waste lots of > > space on your flash filing system :( > Well, "lot's of" would be maybe 3 or 4. Most people only have one list > of favourites. > > (My idea wasn't to put each *service* into an own file, but each *list* > (like group/movies/action, group/movies/horror, ...). sorry if i didn't > made this clear) Will there be a "list of lists"? I.e. how is the order of favourites lists in the menu defined (to make sure that "daddy's list" comes first)? Flash file systems don't waste much space for small files, so having a number of small files is not an issue. Johannes
