On Saturday 16 July 2005 01:30, Kenneth Aafl?y wrote:
> 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.
Thinking about this, I think we're talking about different things...
Felix was wanting to use the existing file format (multiplexes.conf) and
parsing code (backend) to parse individual lines of the file.
However what he _didn't_ want was the rest of the "frontend" of the library -
the structures I defined etc etc as his STB application already has code to
store this stuff that he doesn't/can't change. Basically he just wants to use
and parse the file format with as little else in the way as possible.
Whereas you're suggesting ways to allow people to use the same
frontend/library API, but vary the backend. Which is good as well! But this
explains why I was confused by your suggestions :)
So to begin again:
For the default backend code, we have my suggestion (or a variant of it or
something - we'll come up with something good I am sure :). Basically Felix
would just use the raw parser calls directly for what he wants.
For the frontend library, we have your suggestion:
struct dvbcfg_parser {
int (*get_next_multiplex)(struct dvbcfg_parser *, struct dvb_multiplex);
int (*get_next_service)(struct dvbcfg_parser *, struct dvb_service);
};
I assume these are meant to be replaced with suitable call implementations
when you replace the backend parser? So.. the frontend/application would work
something like:
application code:
X = alloc_parser_backend();
dvcfg_load_multiplexes(X);
dvbcfg_multiplex.c:
dvbcfg_load_multiplexes(X) {
while(!X->get_next_multiplex(P, M))
while(!X->get_next_service(P, S))
}
