Hi Andrew, >>Note that this is just for discussion - if people get me convinced that >>the extra space is worth it, i'll be happy. (Before people start telling >>me that discspace is cheap: flash storage isn't, at least not NOR. When >>you're limited to 8MB for your whole system, you start thinking about >>optimizing such stuff. :) > heh :) > Hmm, we could shorten the names of things - e.g. [multiplex] -> [m] and stuff > like that. Would gzipping the file be of any help, or would that slow things > down too much? Hr, i knew that the "you can compress that" comes up ;) 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? If it does, it's a strong argument for long names. The next question then would be still, if it's ever supposed to edit the file by hand? 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. >>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? > [... 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. And you can feed in the data from whatever source. Though this stuff is probably always read from a file, i generally like to let the application do the "OS depending" stuff, especially because it's relatively easy here (never more than one "result" per line). It's really only a design decision - i don't like callbacks, but that's just my opinion. oh, another thing: If you don't use callbacks, you can easily write wrappers for other languages. Using callbacks, this really really gets difficult. for example with "swig" you can generate the wrapper code automatically, and with my draft, you don't need any specials things, it would just work. >>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. Sure.. My current idea is a simplistic structure like [presets] name="My Favourite channels" [service] gsid = S5E:00:23:523:22:90 [service] gsid = S5E:00:23:523:xx:xx [service] gsid = S5E:00:23:523:xx:xx name = "a renamed channel" icon = "an/icon/different/than/the/default.ico" (with the same thoughts as on 1.) - all the [services] could be removed, as it's pretty clear that each service starts with "gsid". but that's just cosmetic) it's pretty much the same as your proposal. > 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) regards, Felix
