l?rdag 16. juli 2005, 02:15, skrev Andrew de Quincey:
> 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]
> > > 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.
[snip]
> > 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:
The frontend is the framework that the user of the library uses,
the backend is what gives the configuration to the library.
> > 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?
I'm thinking in generics, try this:
struct dvbcfg_parser {
int (*get_multiplexes)(struct dvbcfg_parser *, struct dvb_multiplexes **);
int (*get_next_multiplex)(struct dvbcfg_parser *, struct dvb_multiplex **);
int (*get_next_service)(struct dvbcfg_parser *, struct dvb_service **);
};
Where the calls in the quoted mail would be pretty wrappers or something.
Does that make it clearer? :)
> > 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 :)
Since you are the designer of the parser framework, you could make a rule
that says that the backend parser is handing off structures to the library
for safe keeping or something :)
> 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).
I think he is right, because it's not how data is stored that matters!
It's the structure that it is used in the library and how it is presented
to the user of the library that matters.
IMHO, the "default" backend (the one that retrieves the data) should be pretty
much what you have right now, exept from some new wrapping.
Kenneth
