On 6/29/06, Andrew Phillips <address@hidden> wrote:
> On 6/29/06, Kai Sterker <address@hidden> wrote:
> >
> > I'm wondering ... any editor should be able to write data files that
> > are directly usable by the engine. Basically, there are/will be two
> > formats that are equivalent. A binary format and a ASCII format (which
> > needs a few tweaks and a functional parser yet).
>
> That's good to know.
Basically, each class that requires it has a put_state and get_state
method that will serialize its current state. Everything is collected
in memory first and can finally be passed to a writer (or transfered
over the network, should the need arise). So it would save a little
work if the editors actually used the classes of the engine. (It's a
little different with dlgedit, as dialogues aren't data files but
python scripts.)
> At this point, the 'output' consists of some labels in a pane at the
> bottom of the screen. Their captions change as the data changes. I'm
> not ready to worry about file formats or even file handling. But yes,
> once we decide on a file format, we can teach the editors to read it.
> I merely proposed XML because it lends itself to structured data,
> (including key/value pairs, I think) can be checked for data integrity
> via DTD, and logically compliments my original Perl/CGI/HTML idea.
Makes me think about replacing the sad ASCII file format with XML, as
I haven't invested a lot of time anyway. Since libxml is already a
dependency required for config files, it wouldn't be too difficult.
Actually, I like that idea. Should I come up with a format definition?
Kai