Kickstarting the project again

[Nicolas Alvarez]

We seem to have stalled. We started working on the configuration file, then
argued for a while about an XML parser, and... silence. The last commit to
the SVN repository was a *month* ago.

What needs to be done? We need to choose an XML parser, and parse the
configuration file. And do something useful with what we parse.

On "do something useful with what we parse"...
We need to see how to connect the configuration parser with the rest of the
client. Will there be a 'configuration' object that the parser fills in and
everything else reads, like there is already for cc_config?

On the "choose XML parser"...
in order to get the project un-stalled, if nobody else shows some activity
or objections (like starting to work on a XSD/e parser for the config file)
I'll use my expat wrapper over your dead bodies ;)

--
Nicolas

I read mailing lists through Gmane. Please don't Cc me on replies; it makes
me get one message on my newsreader and another on email.

[Michael Tughan]

I've got nothing currently on my list for cross-project stuff. I am/was in the middle of rewriting the system menu icon on Mac to use Cocoa instead of Carbon, which has been deprecated for a couple years now.

I don't have any opinions on XML parsers right now, I can let everyone know if that changes.

Michael

[Der Meister]

Nicolas Alvarez wrote:
> On "do something useful with what we parse"...
> We need to see how to connect the configuration parser with the rest of the
> client. Will there be a 'configuration' object that the parser fills in and
> everything else reads, like there is already for cc_config?

I'd prefer it this way. Otherwise you would need to change the
configuration object each time you add a new component to push the
required data into that new component. And the configuration object
would need to know which set of data each component needs. I'd call this
a bad design. The configuration object should just parse and update the
configuration file, hold the data and provide methods to read and update
that data from other components. This is more or less the current
situation but maybe some more encapsulation should be used, for example
no global variable to access the configuration object but rather a
function or something like that. And access to the data should be done
via well defined interface instead of direct access to member variables
(wich might be replaced by a map or something like this to keep the
configuration object simple, etc).

> On the "choose XML parser"...
> in order to get the project un-stalled, if nobody else shows some activity
> or objections (like starting to work on a XSD/e parser for the config file)
> I'll use my expat wrapper over your dead bodies ;)

Just go ahead. Real life still keeps me busy and I'm afraid this won't
change much in the next weeks/months.