On Saturday 16 July 2005 00:49, Kenneth Aafl?y wrote:
> l?rdag 16. juli 2005, 01:14, skrev Andrew de Quincey:
> > OK, I've been thinking about this. It makes it quite hard to do nicely
> > for the section oriented file formats. e.g. for multiplexes.conf:
>
> [snip]
>
> > When you're parsing the [m], you only know it ends when you hit the [s]
> > entry... this doesn't really fit nicely if you're passing it line by
> > line, and its not really feasible to go back to a line-oriented format
> > for these more complex files. So need to keep more complex state between
> > lines for these... something like:
> >
> > struct multiplex_parser {
> > int state;
> >
> > struct dvbcfg_multiplex* multiplex;
> > struct dvbcfg_service* service;
> > };
> >
> > int dvbcfg_multiplex_parse_line(char* line, struct multiplex_parser*
> > state);
> >
> > The return code will indicate what was just parsed. Its up to you to
> > supply/update/free suitable multiplex and source pointers - they could be
> > malloced(), they could be pointers to a local temporary variables..
> >
> > Unfortunately, parsing the entries will have to allocate temporary space
> > - e.g. for storing a list of dvbcfg_pid entries. Is this ok?
> >
> > I'll be adding a call to zap the contents of a multiplex structure so you
> > could either just let the parsing accumulate values in the multiplex
> > structure OR you could copy them out to some other place, and zap the
> > structure contents each time something is parsed.
> >
> > What do you think?
>
> What if you don't think about the file format, but of the general
> structure: Don't mind the XML, it's only used to present the format.
>
> <multiplexes ...>
> <multiplex ...>
> <service .../>
> ...
> </multiplex>
> <multiplex .../>
> ....
> </multiplexes>
>
> You start with:
>
> int dvbcfg_create_parser(struct dvbcfg_parser **);
>
> Which allocates a new backend parser, then:
I'm not sure what is the backend and what is the frontend... I was calling the
bit that does the raw parsing the backend, and whatever uses that the
frontend... which may explain my confusion in the following:
> int dvbcfg_get_multiplexes(struct dvbcfg_parser *, struct dvb_multiplexes
> **);
> int dvbcfg_get_next_multiplex(struct dvbcfg_parser *, struct
> dvb_multiplex **);
> int dvbcfg_get_next_service(struct dvbcfg_parser *,
> struct dvb_service **);
I'm not totally sure where these fit in - are they the backend calls to parse
the raw file data?
> A -EOVERFLOW or NULL value in the ptr-ptr parameter says end of list.
> The backend can then choose to pre-parse the multiplexes in
> get_multiplexes, and only keep track of where it is via the parser context.
>
> The parsing in the backend itself can be helped with the string parsers
> already present in dvbcfg, but it is actually free to store the data
> in any format it chooses.
I'm not sure how it is free if the above calls are the backend parsing
calls.... hmm, if they're not, sorry I am confused :)
One thing Felix suggested was not limiting how the data is retrieved - which
is why I had it reading the data line by line - so it could be up to the app
to get the data from "somewhere" (the "default" frontend implementation would
read it from a file on disk).
